perm filename CLEDIT.MSG[COM,LSP]10 blob
sn#863298 filedate 1988-11-07 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00059 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00009 00002 ∂31-Mar-88 1358 chapman%aitg.DEC@decwrl.dec.com editorial subcommittee notes
C00025 00003 ∂03-May-88 0658 CL-Editorial-mailer EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
C00028 00004 ∂03-May-88 0909 CL-Editorial-mailer Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
C00031 00005 ∂03-May-88 1114 CL-Editorial-mailer editorial committee meeting
C00032 00006 ∂03-May-88 1118 CL-Editorial-mailer EDITORIAL-COMITTEE-STANDARD-REVIEW
C00044 00007 ∂03-May-88 1251 CL-Editorial-mailer EDITORIAL-COMITTEE-STANDARD-REVIEW
C00049 00008 ∂03-May-88 1302 CL-Editorial-mailer re:barmar comments
C00051 00009 ∂05-May-88 2216 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
C00064 00010 ∂06-May-88 0934 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
C00066 00011 ∂26-May-88 0728 CL-Editorial-mailer EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
C00069 00012 ∂26-May-88 0807 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
C00072 00013 ∂26-May-88 1007 CL-Editorial-mailer hard copy
C00075 00014 ∂26-May-88 1123 CL-Editorial-mailer $$'s for Words
C00077 00015 ∂26-May-88 1134 CL-Editorial-mailer re: Sonya's comments
C00081 00016 ∂26-May-88 2052 CL-Editorial-mailer editorial committee meeting
C00086 00017 ∂10-Jun-88 0909 CL-Editorial-mailer standard mailing
C00088 00018 ∂16-Jun-88 1621 CL-Editorial-mailer Comments on the snapshot version
C00092 00019 ∂05-Jul-88 1129 CL-Editorial-mailer Editorial Committee Meetings - June
C00112 00020 ∂19-Jul-88 1046 CL-Editorial-mailer just to let you know
C00114 00021 ∂26-Jul-88 0613 CL-Editorial-mailer standard mailing
C00115 00022 ∂06-Aug-88 0325 CL-Editorial-mailer mailing list change
C00116 00023 ∂06-Aug-88 0326 CL-Editorial-mailer mailing list change
C00117 00024 ∂08-Aug-88 1243 CL-Editorial-mailer CL standard
C00119 00025 ∂23-Aug-88 0749 CL-Editorial-mailer standard
C00120 00026 ∂23-Aug-88 0907 CL-Editorial-mailer standard
C00122 00027 ∂30-Aug-88 0858 CL-Editorial-mailer questions
C00125 00028 ∂30-Aug-88 1056 CL-Editorial-mailer Re: questions
C00127 00029 ∂30-Aug-88 1350 CL-Editorial-mailer questions
C00131 00030 ∂30-Aug-88 1615 CL-Editorial-mailer questions
C00134 00031 ∂31-Aug-88 1459 CL-Editorial-mailer questions
C00136 00032 ∂31-Aug-88 1459 CL-Editorial-mailer questions
C00138 00033 ∂02-Sep-88 2136 CL-Editorial-mailer wording about Symbols
C00140 00034 ∂06-Sep-88 1348 CL-Editorial-mailer Notation in standard for function argument/value types
C00143 00035 ∂06-Sep-88 1414 CL-Editorial-mailer Notation in standard for function argument/value types
C00145 00036 ∂06-Sep-88 1450 CL-Editorial-mailer Re: Notation in standard for function argument/value types
C00147 00037 ∂06-Sep-88 2131 CL-Editorial-mailer Notation in standard for function argument/value types
C00151 00038 ∂06-Sep-88 2346 CL-Editorial-mailer Re: Notation in standard for function argument/value types
C00153 00039 ∂07-Sep-88 1017 CL-Editorial-mailer Audience of the Standard
C00156 00040 ∂09-Sep-88 1217 CL-Editorial-mailer type specifiers
C00158 00041 ∂12-Sep-88 0843 CL-Editorial-mailer committee
C00159 00042 ∂12-Sep-88 1037 CL-Editorial-mailer Issue: CLOS-:initform-typographical-errors
C00169 00043 ∂19-Sep-88 1439 CL-Editorial-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C00178 00044 ∂19-Sep-88 1505 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C00180 00045 ∂19-Sep-88 1542 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C00191 00046 ∂28-Sep-88 1344 CL-Editorial-mailer [Robert S. Boyer <boyer@CLI.COM>: Clean Up]
C00194 00047 ∂28-Sep-88 1442 CL-Editorial-mailer as if you haven't got enough to review
C00216 00048 ∂28-Sep-88 1707 CL-Editorial-mailer as if you haven't got enough to review
C00226 00049 ∂29-Sep-88 1220 CL-Editorial-mailer re: barmar comments on error paper
C00238 00050 ∂29-Sep-88 1404 CL-Editorial-mailer re: barmar comments on error paper
C00250 00051 ∂03-Oct-88 1125 CL-Editorial-mailer
C00262 00052 ∂03-Oct-88 1233 CL-Editorial-mailer October agenda
C00266 00053 ∂03-Oct-88 1255 CL-Editorial-mailer error definitions
C00277 00054 ∂03-Oct-88 1406 CL-Editorial-mailer Error Terminology
C00279 00055 ∂03-Oct-88 1429 CL-Editorial-mailer Error Terminology
C00284 00056 ∂04-Oct-88 0951 CL-Editorial-mailer barmar questions about error terms
C00287 00057 ∂04-Oct-88 1101 CL-Editorial-mailer Error Terminology
C00290 00058 ∂04-Oct-88 2041 X3J13-mailer Re: error definitions
C00294 00059 ∂05-Oct-88 0021 CL-Editorial-mailer Re: Error Terminology
C00296 ENDMK
C⊗;
∂31-Mar-88 1358 chapman%aitg.DEC@decwrl.dec.com editorial subcommittee notes
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 31 Mar 88 13:58:43 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA15156; Thu, 31 Mar 88 13:52:57 PST
Date: Thu, 31 Mar 88 13:52:57 PST
Message-Id: <8803312152.AA15156@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: @[chapman]eddis@decwrl.dec.com, chapman%aitg.DEC@decwrl.dec.com
Subject: editorial subcommittee notes
Editorial Subcommittee Report
March, 1988
1 INTRODUCTION
The editorial subcommittee of X3J13 met on March 15, 1988,
from 2-5 PM at Lucid. Attendees were:
Skona Brittain Barry Margolin
Kathy Chapman Larry Masinter
Linda deMicheal Guy Steele
Dick Gabriel Walter van Roggen
Sonya Keene Bob Mathis
(did I leave anyone out?)
This memo summarizes the important results of the meeting,
and lists the action items from the meeting.
2 SUMMARY
In general, the attendees felt that the schedule for
completion of the standard was agressive, but doable. In
addition, there is an increased interest in completing the
standard on, or ahead of, schedule, due to the commitment the US
has made to the ISLISP group. Following are the decisions made by
the attendees.
1. The outline and contents of the chapters of the standard have
been modified. The next section of this memo details the
changes.
2. A formal specification of the base forms of CL will be done.
It will begin in July or sooner. Initially the work will be
done by Dick Gabriel and Kathy Chapman. It is hoped that Will
Clinger and Jonathan Rees will have time to assist with the
effort.
3. It was decided that the use of a large set of special fonts in
explanatory material (will be Chapter 3 in the new outline) is
distracting to the reader. Therefore, special fonts will only
be employed to a limited extent in Chapter 3, but will be used
more extensively in Chapter 4 (see Action Items section).
!
Page 2
4. It was decided that the use of a professional indexer is
probably desirable (see Action Items section).
5. The reader syntax and semantic rules, and other semantic rules
of the language CL, will be specified in natural language in
the form of a set of evaluation rules. These will appear in
Chapters 2 and 3 (see outline in the next section) (see Action
Items section).
6. It was decided that the issues surrounding language extensions
should be examined in detail (see Action Items section).
7. A new list of parts of the document to be reviewed, when they
will be ready for review, and who is to review them, is to be
constructed (see Action Items section).
3 NEW OUTLINE AND CONTENTS OF STANDARD CHAPTERS
Following is the new outline for the CL standard.
1. Chapter 1 - Introduction - Same outline as current chapter 1;
font key explanation is expanded, compliance section is
rewritten with clarity in mind, language extensions section is
modified (see Action Items).
2. Chapter 2 - Evaluation - This chapter will contain a clear
model of read, eval, phases of processing... (see Action
Items).
3. Chapter 3 - Concepts - This chapter will contain the following
information:
1. A description of the Lisp reader, and a forward reference
to the read function. In addition, the character set will
appear first, and all the syntactic characteristics
(whether they involve `special' tokens or not), will
appear in the list of operators.
2. The data types section will contain an explanation of the
way CL uses data types.
3. The basic language constructs section will be moved to
Chapter 2 (the evaluation model).
4. The rest of this chapter will contain information similar
to what is contained in Chapter 1 of the CLOS
specification, i.e., an explanation of how the language
works with forward pointers to forms that will be
explained in detail (but autonomously) in Chapter 4.
!
Page 3
4. Chapter 4 - Form, Constant, and Variable Descriptions - This
chapter now includes the information that had previously been
a part of Chapters 4, 5, and 7. Following are some details
about how this chapter will look.
1. All functions, macros, special forms, constants, and
variables that are part of CL will be listed
alphabetically. All entries with non-alpha characters
appearing in the first position of the name of the entry
will be positioned at the end of the alphabetic list, and
will be alphabetized according to the first alpha or
numeric character appearing in the name of the entry.
2. The `Inputs' and `Outputs' labels in the f/m/sf
descriptions are changed to `Arguments' and `Values',
respectively.
3. The `Base' label is removed, and the fact that a f/m/sf is
part of the base is notated under the label `Notes'.
4. A `Side Effects' label has been added.
5. A `See Also' label was suggested; however, its meaning in
a strict specification is not clear. For example, does a
See Also reference mean that the information pointed to
somehow affects the result of the evaluation of the form
being described? Please comment on the addition of a `See
Also' label.
5. Chapter 5 - Syntax - same as current Chapter 8.
6. Chapter 6 - Semantics - same as current Chapter 9.
!
Page 4
4 ACTION ITEMS
Following is a list of action items resulting from both the
subcommittee meeting, and the X3J13 committee meeting. Please let
me know if I missed any items, or have incorrectly assigned an
item to a person.
Responsible people Action Item
Kathy Chapman Get X3 to pay for professional indexer
Kathy Chapman Create a format for proposal submission
Barry Margolin Create a proposal on how language extensions are
Larry Masinter to be handled
Guy Steele Create an evaluation model strawman
Dick Gabriel
Kathy Chapman Create a review cycle proposal for editorial
committee reviews
Kathy Chapman Create a review proposal for X3J13 committee
Kathy Chapman Contact typesetter to review font usage
5 OPEN ISSUES
Following is a list of decisions that have to be made at
future meetings.
1. Will new language features (like CLOS) be imbedded in the
document or will they appear as a supplement?
2. Should we specifically try to include the ISO community in our
review cycles?
3. Other issues?
6 SUMMARY
The people that reviewed the document provided highly
valuable technical insight and corrections. In order for us to
make this document as correct as possible, it will be necessary
for this sort of review to continue to the document's completion.
!
Page 5
As the document becomes larger and larger, this sort of review
becomes more and more intimidating and time-consuming. Therefore,
I'd like to request help now working out the review cycle details,
and later changing the review cycle algorithm if it doesn't work
for you. It would be much better to speak up if you don't have
time to review your part than to leave it left unread.
The first request I have may be the most important to our
success. A review cycle plan will be coming to you within this
month. Please review it carefully, analyze the time you will have
to spend on this effort, and propose a task you can comfortably
accomplish. If I don't hear from you concerning the review cycle
plan, I will assume you do not wish to review the standard. If
you are passing the document around to other people, please make
sure they realize that their timely review is necessary to the
success of this effort. An unreviewed section could potentially
remain untouched, and perhaps will be wrong. Urge the people you
are counting on to review certain parts to only volunteer for as
much as they can handle.
∂03-May-88 0658 CL-Editorial-mailer EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 06:58:43 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04677; Tue, 3 May 88 06:58:45 PDT
Date: Tue, 3 May 88 06:58:45 PDT
Message-Id: <8805031358.AA04677@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Issue: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/4/88
Problem Description: The editorial committee needs a standard format
for submitting proposals
Proposal: Proposals to the editorial committee should be submitted
in the following format to cl-editorial@sail.stanford.edu.
Issue: <title of issue>
Category: <administrative/technical>
Edit History: <version # - author - date>
Problem Description: <why this issue was raised>
Proposal: <solution to the issue>
Rationale: <why this solution was chosen>
Current Practice: <how the issue is currently dealt with>
Cost to Implementors: <what the solution will cost vendors to implement>
Cost to Users: <how will this solution change a user's view>
Cost of Non-adoption: <what will happen if nothing is done about the issue>
Benefits: <what added value this solution provides>
Discussion: <discussion about this issue/solution>
Rationale: Familiar, looks very similar to the clean-up committee
proposal format.
Current Practice: No proposals have been submitted yet.
Cost to Implementors: None.
Cost to Users: None.
Cost of Non-adoption: Non-standard formats for proposals will cause confusion.
Benefits: Tracking of issues with the CL standard will be easier.
Discussion:
∂03-May-88 0909 CL-Editorial-mailer Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 88 09:09:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 MAY 88 09:03:07 PDT
Date: 3 May 88 09:02 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 3 May 88 06:58:45
PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <880503-090307-5141@Xerox>
I think the editorial committee will need some less cumbersome mechanisms than
those adopted by the cleanup committee; the problem in cleanup is that there
were a lot of substantive issues that actually had costs and benefits to diverse
communities. I think given the schedule you should go for something leaner:
i.e., Cathy Chapman makes the decisions, and asks the editorial committee for
advice & review.
With cl-cleanup, there were lots of proposals and no action, and the standard
format helped focus the discussions into the technical merits. Here, I don't see
a lot of proposals at all -- maybe you do? Are there some you are having trouble
dealing with?
I have difficulty dealing with the abstract; maybe a concrete example of what
you think of as an "editorial committee proposal" might help me understand what
you're getting at.
∂03-May-88 1114 CL-Editorial-mailer editorial committee meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 11:14:31 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA17581; Tue, 3 May 88 11:14:32 PDT
Date: Tue, 3 May 88 11:14:32 PDT
Message-Id: <8805031814.AA17581@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: editorial committee meeting
I have requested a conference room for 6/14 in the afternoon for our
committee meeting. Does anyone have a problem with this?
kc
∂03-May-88 1118 CL-Editorial-mailer EDITORIAL-COMITTEE-STANDARD-REVIEW
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 11:18:15 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA17653; Tue, 3 May 88 11:18:12 PDT
Date: Tue, 3 May 88 11:18:12 PDT
Message-Id: <8805031818.AA17653@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: EDITORIAL-COMITTEE-STANDARD-REVIEW
Issue: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/5/88
Version 2, Kathy Chapman, 5/1/88
Problem Description:
Part 1: Reviewers must receive the parts of the
standard they are meant to review either electronically or
by hardcopy.
Part 2: Reviewers must be able to comment on those sections
they are reviewing electronically or by hardcopy.
Part 3: Reviewers' comments must be incorporated, logged, and
responded to electronically or by hardcopy.
Part 4: Reviewers must have access to the complete standard and
to the marked-up CLtL with pointers to the standard.
Proposal:
The files containing
the standard are to be located in TEX format on
chapman@hudson.dec.com::sys$sysdevice:[chapman]*.tex.
The review and comment process, if conducted electronically,
will be handled by a mail monitor. A set of functions will be
available to each group of reviewers (X3 committee, editorial
committee, and others) which will facilitate the review process.
If electronic access is not possible, it is possible to request
a hardcopy in writing or telephonically.
A summary of the mail monitor functions applicable to the X3
committee follow: (use `cl-review' as subject)
Function Keywords Description
request hardcopy (t or nil) The latest copies of all
files (list) sections you are responsible
for will be copied to
chapman@hudson.dec.com,
or mailed to your hardcopy
address (see list below).
comment file (string) The file being reviewed.
qualifier (string) Section # or contruct name.
comment (string) The comment.
A response to the comment is
sent to the reviewer and
cl-editorial. The possible
files are listed below.
update update-frequency Amount of time (in days) be-
(integer) tween copies of the standard
to hudson.dec.com (initially
this is every 30 days).
change hardcopy-address (string) Use this function to change
file-list (list) the information in the data
base that is part of this
message. You can only change
your own information.
query all-files (t or nil) Get a list of possible files
file-list (list) to review, your file list,
update-frequency current update frequency,
comment-list current list of comments.
In addition, to aid in reviewing, the mapping from the CLtL to
the standard and visa versa will be located on hudson.dec.com
in the files cltl-standard.txt and standard-cltl.txt.
Examples:
To request a hardcopy:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (request :hardcopy t :files '(all))
To comment on a chapter or section:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (comment :chapter chap3 :qualifier "3.1.1.2" :comment
"Paragraph 2: change wording from
function to macro")
Possible files are:
all (this means all you are responsible for reviewing)
book (this means the whole standard)
chap1
chap2
chap3
ARRAYS
CHARACTERS
CONTROL-STRUCTURE
DECLARATIONS
ERRORS
EVALUATOR
FILES
HASHTABLES
IO
LISTS
MACROS
MISC
NUMBERS
PACKAGES
PREDICATES
PROGRAM-STRUCTURE
SEQUENCES
STREAMS
STRINGS
STRUCTURES
SYMBOLS
TYPES
chap5
chap6
new-additions
Rationale: In order to get the standard done in a timely manner, it
is necessary that the review process be stream-lined, but
flexible.
Current Practice: None.
Cost to Implementors: If a reviewer requests a hardcopy, it will be
sent COD.
Cost to Users: Same as Cost to Implementers.
Cost of Non-adoption: The review process could, in the best case, become
unwieldy. In the worst case, reviewers could find that reviewing
the document and submitting comments is too much trouble, and
the document would thus not get reviewed.
Benefits:
1. Reviewers can review according to when their own schedules
permit, not just when the document is available.
2. Comments can be handled and logged automatically.
Discussion: Following are the default data base and the proposed review
schedule.
The default data base follows:
Sender Data
maxiv@mu.edu "Mary Boelk
Johnson Controls, MS M67
507 East Michigan St.
Milwaukee, Wisconsin 53202"
(chap1 chap3 packages symbols)
skona%csilvax@hub.ucsb.edu
"Skona Brittain
Microcomputer System Consultants
P.O. Box 747
Santa Barbara, California 93102"
(chap1 chap3 arrays control-structure declarations)
Willc%tekchips.crl@tektronix.tek.com
"Will Clinger
Semantic Microsystems
4470 SW Hall Blvd., Suite 340
Beaverton, Oregon 97005"
(chap1 chap3 chap5 chap6)
rpg@sail.stanford.edu
"Dr. Richard Gabriel
Lucid, Inc.
707 Laurel St.
Menlo Park, California 94025"
(chap1 chap2 chap3 chap5 chap6)
ida%utokyo-relay.csnet@csnet-relay.arpa
"Masayuki Ida
Aoyama Cakuin University
Computer Science Research Group
Atsugi, Kanagawa JAPAN 243-01
(book)
Gregor.pa@xerox.com
"Gregor Kiczales
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 clos)
barmar@think.com
"Barry Margolin
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap3 structures evaluator)
Masinter.pa@xerox.com
"Larry Masinter
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 files hashtables io)
mathis@c.isi.edu
"Bob Mathis
9712 Ceralene Dr.
Fairfax, Virginia 22032-1704"
(chap1 chap3 numbers)
ohlander@VENERA.ISI.EDU
"Ron Ohlander
USC-ISI
4676 Admiralty Way
Marina del Rey, California 90292"
(chap1 chap3 lists macros)
KMP@SCRC-Stony-Brook.arpa
"Kent M. Pitman
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 misc errors types)
jar@ai.ai.mit.edu
"Jonathan Rees
MIT
39 Clarendon St.
Boston, Mass. 02116"
(chap1 chap2 chap3 chap5 chap6)
jeffr@aai2.istc.sri.com
"Jeff Rininger EK339
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025"
(chap1 chap3 predicates program-structure)
Rosenking@a.isi.edu
"Jeff Rosenking
Grumman Corporate Research Center
M/S A01-26
Bethpage, NY 11714"
(chap1 chap3 sequences streams)
SKeene@SCRC-Stony-Brook.arpa
"Sonya Keene
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 strings characters)
gls@THINK.com
"Dr. Guy L. Steele Jr.
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap2 chap3)
∂03-May-88 1251 CL-Editorial-mailer EDITORIAL-COMITTEE-STANDARD-REVIEW
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 May 88 12:51:31 PDT
Received: from fafnir.think.com by Think.COM; Tue, 3 May 88 15:49:55 EDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by fafnir.think.com; Tue, 3 May 88 15:49:50 EDT
Date: Tue, 3 May 88 15:51 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: EDITORIAL-COMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8805031818.AA17653@decwrl.dec.com>
Message-Id: <19880503195119.9.BARMAR@OCCAM.THINK.COM>
I don't understand this:
Function Keywords Description
request hardcopy (t or nil) The latest copies of all
files (list) sections you are responsible
for will be copied to
chapman@hudson.dec.com,
or mailed to your hardcopy
address (see list below).
If I request a section, why will it be copied to chapman, rather than
mailed to me?
Actually, I think that transmission of sections should be done using
file transfer if feasible. Would it be possible for the sections to be
placed on a machine connected to the Arpanet, to which we could get FTP
access? Email is a very poor mechanism for distribution of large
documents.
comment file (string) The file being reviewed.
qualifier (string) Section # or contruct name.
comment (string) The comment.
A response to the comment is
sent to the reviewer and
cl-editorial. The possible
files are listed below.
I don't like having to enclose the actual comment text in a string. I
think it would be better to have the list at the beginning of the
message text, and then take the rest of the message as the text of the
comment. If you want to allow multiple comments in a single message, we
could devise an escape sequence that indicates that another comment
descriptor follows, e.g.
(comment :file chap3 :qualifier "3.1.1.2")
Blah, blah, blah.
Comment, comment, comment.
-*-End-*-
(comment :file chap1 :qualifier "1.3")
More blah, blah, blah.
Requring the comment to be in a string is prone to errors, because we
may forget to slashify doublequotes and slashes when we include them in
the comment (and we will, I guarantee it). A sequence like the above
"-*-End-*-" is unlikely to appear in a real comment.
To comment on a chapter or section:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (comment :chapter chap3 :qualifier "3.1.1.2" :comment
"Paragraph 2: change wording from
function to macro")
The :chapter keyword isn't mentioned in the above description of the
"comment" operation. Should that be :file?
barmar
∂03-May-88 1302 CL-Editorial-mailer re:barmar comments
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88 13:02:21 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA22604; Tue, 3 May 88 13:02:23 PDT
Message-Id: <8805032002.AA22604@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 88 16:02
To: cl-editorial@sail.stanford.edu
Subject: re:barmar comments
>Actually, I think that transmission of sections should be done using
>file transfer if feasible. Would it be possible for the sections to be
>placed on a machine connected to the Arpanet, to which we could get FTP
>access? Email is a very poor mechanism for distribution of large
>documents.
That's the idea, that's why the files are being copied to a node
that has FTP access, and then you can do the copy. Mail won't work
in this case. I'd like to do the FTP automatically, but can't promise
that right now.
No strings for comments, yes it should be :file.
kc
∂05-May-88 2216 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 May 88 22:16:06 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04054; Thu, 5 May 88 22:16:11 PDT
Date: Thu, 5 May 88 22:16:11 PDT
Message-Id: <8805060516.AA04054@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Issue: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/5/88
Version 2, Kathy Chapman, 5/1/88
Version 3, Kathy Chapman, 5/6/88
Problem Description:
Part 1: Reviewers must receive the parts of the
standard they are meant to review either electronically or
by hardcopy.
Part 2: Reviewers must be able to comment on those sections
they are reviewing electronically or by hardcopy.
Part 3: Reviewers' comments must be incorporated, logged, and
responded to electronically or by hardcopy.
Part 4: Reviewers must have access to the complete standard and
to the marked-up CLtL with pointers to the standard.
Proposal:
The files containing
the standard are to be located in TEX format on
chapman@hudson.dec.com::sys$sysdevice:[chapman]*.tex.
This machine has FTP access so that you can copy the
files you need to your location.
The review and comment process, if conducted electronically,
will be handled by a mail monitor. A set of functions will be
available to each group of reviewers (X3 committee, editorial
committee, and others) which will facilitate the review process.
If electronic access is not possible, it is possible to request
a hardcopy in writing or telephonically.
A summary of the mail monitor functions applicable to the X3
committee follow: (use `cl-review' as subject)
Function Keywords Description
request hardcopy (t or nil) The latest copies of all
files (list) sections you are responsible
for will be copied to
chapman@hudson.dec.com,
or mailed to your hardcopy
address (see list below).
comment file (string) The file being reviewed.
qualifier (string) Section # or contruct name.
A response to the comment is
sent to the reviewer and
cl-editorial. The possible
files are listed below.
update update-frequency Amount of time (in days) be-
(integer) tween copies of the standard
to hudson.dec.com (initially
this is every 30 days).
change hardcopy-address (string) Use this function to change
file-list (list) the information in the data
base that is part of this
message. You can only change
your own information.
query all-files (t or nil) Get a list of possible files
file-list (list) to review, your file list,
update-frequency current update frequency,
comment-list current list of comments.
In addition, to aid in reviewing, the mapping from the CLtL to
the standard and visa versa will be located on hudson.dec.com
in the files cltl-standard.txt and standard-cltl.txt.
Examples:
To request a hardcopy:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (request :hardcopy t :files '(all))
To comment on a chapter or section:
From: decwrl::"rpg@sail.stanford.edu"
To: chapman@hudson.dec.com
Subject: cl-review
Text: (comment :file chap3 :qualifier "3.1.1.2")
Paragraph 2: change wording from
function to macro.
Possible files are:
all (this means all you are responsible for reviewing)
book (this means the whole standard)
chap1
chap2
chap3
ARRAYS
CHARACTERS
CONTROL-STRUCTURE
DECLARATIONS
ERRORS
EVALUATOR
FILES
HASHTABLES
IO
LISTS
MACROS
MISC
NUMBERS
PACKAGES
PREDICATES
PROGRAM-STRUCTURE
SEQUENCES
STREAMS
STRINGS
STRUCTURES
SYMBOLS
TYPES
chap5
chap6
new-additions
Rationale: In order to get the standard done in a timely manner, it
is necessary that the review process be stream-lined, but
flexible.
Current Practice: None.
Cost to Implementors: If a reviewer requests a hardcopy, it will be
sent COD.
Cost to Users: Same as Cost to Implementers.
Cost of Non-adoption: The review process could, in the best case, become
unwieldy. In the worst case, reviewers could find that reviewing
the document and submitting comments is too much trouble, and
the document would thus not get reviewed.
Benefits:
1. Reviewers can review according to when their own schedules
permit, not just when the document is available.
2. Comments can be handled and logged automatically.
Discussion: Following are the default data base and the proposed review
schedule.
The default data base follows:
Sender Data
maxiv@mu.edu "Mary Boelk
Johnson Controls, MS M67
507 East Michigan St.
Milwaukee, Wisconsin 53202"
(chap1 chap3 packages symbols)
skona%csilvax@hub.ucsb.edu
"Skona Brittain
Microcomputer System Consultants
P.O. Box 747
Santa Barbara, California 93102"
(chap1 chap3 arrays control-structure declarations)
Willc%tekchips.crl@tektronix.tek.com
"Will Clinger
Semantic Microsystems
4470 SW Hall Blvd., Suite 340
Beaverton, Oregon 97005"
(chap1 chap3 chap5 chap6)
rpg@sail.stanford.edu
"Dr. Richard Gabriel
Lucid, Inc.
707 Laurel St.
Menlo Park, California 94025"
(chap1 chap2 chap3 chap5 chap6)
ida%utokyo-relay.csnet@csnet-relay.arpa
"Masayuki Ida
Aoyama Cakuin University
Computer Science Research Group
Atsugi, Kanagawa JAPAN 243-01
(book)
Gregor.pa@xerox.com
"Gregor Kiczales
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 clos)
barmar@think.com
"Barry Margolin
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap3 structures evaluator)
Masinter.pa@xerox.com
"Larry Masinter
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, Calif. 94304"
(chap1 chap3 files hashtables io)
mathis@c.isi.edu
"Bob Mathis
9712 Ceralene Dr.
Fairfax, Virginia 22032-1704"
(chap1 chap3 numbers)
ander@VENERA.ISI.EDU "e"
"Ron Ohlander
USC-ISI
4676 Admiralty Way
Marina del Rey, California 90292"
(chap1 chap3 lists macros)
KMP@SCRC-Stony-Brook.arpa
"Kent M. Pitman
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 misc errors types)
jar@ai.ai.mit.edu
"Jonathan Rees
MIT
39 Clarendon St.
Boston, Mass. 02116"
(chap1 chap2 chap3 chap5 chap6)
jeffr@aai2.istc.sri.com
"Jeff Rininger EK339
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025"
(chap1 chap3 predicates program-structure)
Rosenking@a.isi.edu
"Jeff Rosenking
Grumman Corporate Research Center
M/S A01-26
Bethpage, NY 11714"
(chap1 chap3 sequences streams)
SKeene@SCRC-Stony-Brook.arpa
"Sonya Keene
Symbolics, Inc.
11 Cambridge Center
Cambridge, Mass. 02142"
(chap1 chap3 strings characters)
gls@THINK.com
"Dr. Guy L. Steele Jr.
Thinking Machines
245 First St
Cambridge, Mass. 02142"
(chap1 chap2 chap3)
∂06-May-88 0934 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 May 88 09:34:02 PDT
Received: from fafnir.think.com by Think.COM; Fri, 6 May 88 12:31:38 EDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by fafnir.think.com; Fri, 6 May 88 12:31:34 EDT
Date: Fri, 6 May 88 12:33 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
In-Reply-To: <8805060516.AA04054@decwrl.dec.com>
Message-Id: <19880506163301.0.BARMAR@OCCAM.THINK.COM>
This database entry doesn't look right:
ander@VENERA.ISI.EDU "e"
"Ron Ohlander
USC-ISI
4676 Admiralty Way
Marina del Rey, California 90292"
(chap1 chap3 lists macros)
What's the "e" for? All the other entries have a single character
string between the email address and the section list.
barmar
∂26-May-88 0728 CL-Editorial-mailer EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 May 88 07:28:20 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 410625; Thu 26-May-88 10:27:30 EDT
Date: Thu, 26 May 88 10:27 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.STANFORD.EDU
In-Reply-To: <8805031358.AA04677@decwrl.dec.com>
Message-ID: <19880526142701.2.SKEENE@JUNCO.SCRC.Symbolics.COM>
I have the same questions Larry raised about the need for a proposal
format. What kind of proposals do you expect? I think the two kinds
of communications you're going to have with the X3J13 members are:
1. suggestions, general comments, ideas, questions, flames
2. reviews of the draft
The first category can be dealt with informally, which would probably
save administrative time on your part. We used the CLOS mailing list
this way and it worked fine. If we had kept track of those
communications we would never have finished the spec. You could save
the communications (without doing any administrative work) by
archiving the editorial mailing list.
∂26-May-88 0807 CL-Editorial-mailer EDITORIAL-COMMITTEE-STANDARD-REVIEW
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 May 88 08:07:11 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 410651; Thu 26-May-88 11:07:19 EDT
Date: Thu, 26 May 88 11:06 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.STANFORD.EDU, CHAPMAN@decwrl.dec.com
In-Reply-To: <8805060516.AA04054@decwrl.dec.com>
Message-ID: <19880526150653.3.SKEENE@JUNCO.SCRC.Symbolics.COM>
Personally, when I review documentation, I always do it in hardcopy. As
a technical writer, I haven't ever found a reviewer who prefers to do it
online. I don't know if my experience is representative. It is
probably worth asking the group if they see themselves using the
electronic mail tools you proposed.
When I get copies for Symbolians to review, I'll ftp the files to a
local machine and then print them. I don't completely understand the
process for doing that. Do I really have to use a mail monitor program
to copy files? Also, I would want to copy dvi files, not tex files.
How would I do that?
Is there anything ready for review now?
∂26-May-88 1007 CL-Editorial-mailer hard copy
Received: from hub.ucsb.edu by SAIL.Stanford.EDU with TCP; 26 May 88 10:06:35 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA28368; Thu, 26 May 88 10:07:01 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA16346; Thu, 26 May 88 10:00:33 PDT
Date: Thu, 26 May 88 10:00:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 26 May 88 10:00:33 PDT
To: cl-editorial@SAIL.Stanford.edu
Subject: hard copy
I strongly agree with Sonya about reviewing hard copy. All my experience,
as a reviewer and a reviewee, says that hard copy is preferable. At this
point I think that we should postpone discussing ways to do the work until
we start doing it and then see what tools we need to develop, if any. Since
this committee is not overwhelming in size, I don't think that that will
cause problems. Coordinating differences can probably be done by one person.
Mailing hard copy will cost money but I am quite confident that it will save
a lot of time.
I also strongly feel that hard copy should be available free to members of
the editorial committee. I do not understand why this is the only committee
that exacts a monetary price for membership - aren't time, effort, ideas, etc.
enough? At the March meeting two people told me that they agreed with my
position although they hadn't wanted to say so in front of the whole group.
So I suggest that we at least decide among ourselves how we feel about this
policy before the June meeting. I joined this committee because I felt that
it was the one to which I could contribute the most, but if I have to pay to
do so, I will withdraw from it. (as far as I know, ftp'ing files is not free
unless it's a local call, and then they still need to be printed anyway.)
skona
∂26-May-88 1123 CL-Editorial-mailer $$'s for Words
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I am one of the people who suggested that a nomimal fee be paid by folks
who request hardcopy, and the primary targets of this charge are members
of X3J13 who are not in the subcommittee. If the basic part of the Common
Lisp specification will be about 300 pages long, and CLOS, Loop, and error
signaling are part of it, it will cost $4000 to copy and mail it to the
membership. Every CLOS mailing has cost us about $2000 to send out. The
reason is to encourage only those who will actually do the work of
reviewing the material. Another alternative is to raise the membership
fee for X3J13 to cover this cost, so that everyone will pay to get the
hard copies even if they don't want them. It seemed to me better to dun
only those who wanted it rather than everyone.
It's sort of like if you went to a big dinner and you ordered a cheap
meal, but some others ordered expensive ones, and they split the bill
evenly.
-rpg-
∂26-May-88 1134 CL-Editorial-mailer re: Sonya's comments
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 May 88 11:32:24 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA29787; Thu, 26 May 88 11:32:36 PDT
Date: Thu, 26 May 88 11:32:36 PDT
Message-Id: <8805261832.AA29787@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu
Subject: re: Sonya's comments
>From: DECWRL::"skeene@STONY-BROOK.SCRC.Symbolics.COM" "Sonya E. Keene 26-May-88 1106 EDT" 26-MAY-1988 11:03
>To: aitg::chapman
>Subj: EDITORIAL-COMMITTEE-STANDARD-REVIEW
>
>Cc: cl-editorial@SAIL.STANFORD.EDU, decwrl::CHAPMAN
>Personally, when I review documentation, I always do it in hardcopy. As
>a technical writer, I haven't ever found a reviewer who prefers to do it
>online. I don't know if my experience is representative. It is
>probably worth asking the group if they see themselves using the
>electronic mail tools you proposed.
I agree with you, I don't think it's possible to review a document longer
than 1 page from a terminal. The mechanism in the proposal is created
to manage comments and responses to them. It would be helpful to me
if you made comments electronically instead of in your hardcopy, but
even if you don't, that is how they will eventually be tracked.
>When I get copies for Symbolians to review, I'll ftp the files to a
>local machine and then print them. I don't completely understand the
>process for doing that. Do I really have to use a mail monitor program
I don't currently plan to copy my files every day to the FTP machine
(which is not the same as my development machine for security reasons),
only once per month. If you want a more current copy to review, you need
to tell me somehow to copy the file to the FTP machine so you can copy
it.
>to copy files? Also, I would want to copy dvi files, not tex files.
>How would I do that?
I can provide .dvi files, no problem.
>Is there anything ready for review now?
So glad to see you're anxious to review!
You will be receiving another mail message today that addresses when the
review should begin.
kc
∂26-May-88 2052 CL-Editorial-mailer editorial committee meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 May 88 20:52:10 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA24618; Thu, 26 May 88 20:52:22 PDT
Date: Thu, 26 May 88 20:52:22 PDT
Message-Id: <8805270352.AA24618@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
Subject: editorial committee meeting
May 26, 1988
Meeting reminder and status of the standard
There will be a meeting of the editorial subcommittee on June
14, 1988, at 1:00 in the St. Croix Conference room at Symbolics.
Please let me know if you have a problem with the meeting time or
place.
I will be mailing the standard in its current state at the
end of next week.
Since the last meeting, I have been collecting information on
how a review of a document like the standard should be conducted.
One outcome of that exercise is the review proposal you should
have received that outlines a method for managing the review of
the standard and the resulting comments. It also became clear
that limiting the number of times a reviewer had to look at the
same document part was important to a thorough review of the
document. Therefore I suggest that you consider reviewing the
document after the completion of each phase of its life, i.e.
after it is a standardized version of the CLtL, after it has had
all the issues, CLOS, and the condition system incorporated (and
whatever else is going to be part of the standard), and after it
has had all your comments included.
For this meeting, I would like to accomplish the following:
1. I would like to get your concurrence that the review cycle
proposal is adequate, and that I may proceed with its
implementation.
2. Very shortly after this meeting I would like to start making
the phase I version of the standard (the standardized CLtL)
available for your review. For this to be possible, I need to
make sure that you think that at least some parts of the
document are ready for review.
3. A professional indexer can be available to index the standard
if we contract for her services in the near future. I'd like
to close the loop on this issue.
4. Check on the progress of the conformance proposal.
5. Check on the progress of the evaluation model.
6. Report on meetings with professional typesetters and book
designers, as well as the ANSI Editorial tutorial.
Looking forward to seeing you.
kathy chapman
∂10-Jun-88 0909 CL-Editorial-mailer standard mailing
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 10 Jun 88 09:09:32 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA00586; Fri, 10 Jun 88 09:08:30 PDT
Message-Id: <8806101608.AA00586@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 10 Jun 88 12:02
To: cl-editorial@sail.stanford.edu, PASQUALE%aitg.DEC@decwrl.dec.com,
CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: standard mailing
Due to an unavoidable delay, the snapshot of the standard was not mailed
earlier this week as planned. Therefore, the following has been done:
1. There will be extra copies available at the editorial committee
meeting so that we can all look at it as we talk.
2. You should have a copy waiting for you when you get back home,
so there should be no need or you to waste space in your suitcase
(unless you need some light reading on the plane).
3. Borrow a copy from a local edit comm member? What about that,
Kent and Sonya?
Sorry for the inconvenience,
kc
∂16-Jun-88 1621 CL-Editorial-mailer Comments on the snapshot version
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Jun 88 16:20:50 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00793; 16 Jun 88 15:50 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay01482; 16 Jun 88 15:41 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA25593; Thu, 16 Jun 88 22:04:02 JST
Received: by aoyama.cc.aoyama.junet (3.2/6.3Junet-1.0)
id AA02131; Thu, 16 Jun 88 14:53:45 JST
Date: Thu, 16 Jun 88 14:53:45 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@aoyama.cc.aoyama.junet>
Message-Id: <8806160553.AA02131@aoyama.cc.aoyama.junet>
To: cl-editorial@SAIL.STANFORD.EDU
Subject: Comments on the snapshot version
Cc: ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET
Commonts on Fonts/Characters of the draft:
1) backquote character:
I have lots of experiences of trouble caused by the font of backquote sign.
Since in japan, we have not so long history to handle backquote character
in computer languages, Users/Novices often forget to take care of
the difference of quote sign; "'" and "`".
(Especially with bad fonts. )
(So, it may be a japan domestic problem,... but) I think
the choice of the font for quote character is important.
The current choice is quite normal but if possible,
more distinctive fonts will help us.
2) With some relations to backquote issue, definition/explanation
of the character set used in the document:
Since I was an official member of JIS Basic committee and
I joined the working team for check ANSI Fortan77 in japan,
I wonder why there is no section describing the character set
used in the draft, say in chapter 1.
I feel a kind of following table might be inserted.
The Character Set used in this Standard
symbol meaning
( open parenthesis or left parenthesis
) close parenthesis or right parenthesis
+ plus
...
' quote or single quote
` backquote
...
Masayuki Ida
∂05-Jul-88 1129 CL-Editorial-mailer Editorial Committee Meetings - June
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 Jul 88 11:29:34 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA04673; Tue, 5 Jul 88 11:29:06 PDT
Message-Id: <8807051829.AA04673@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 5 Jul 88 14:27
To: cl-editorial@sail.stanford.edu
Subject: Editorial Committee Meetings - June
Editorial Committee Meetings
June 14, 1987 and June 16, 1987, Boston
Attendees (at one or both meetings): Mary Boelke, Skona
Brittain, Kathy Chapman, Linda deMicheal, Dick Gabriel, Sonya
Keene, Barry Margolin, Bob Mathis, Jeff Piazza, Kent Pitman,
Jonathan Rees, Jeff Rosenking, Guy Steele, Walter van Roggen
1 SUMMARY OF ACTION ITEMS
It was agreed that phase 1 of the standard would be ready for
review by mid-July. This version may not contain all the changes
recommended at the editorial committee meeting and listed below.
However, those changes will be incorporated before the completion
of phase 2 if they are not in phase 1.
It was also agreed that the committee would try to have a
completed phase 1 document by the fall meeting. This means that
changes by the section writers will have to be to the editor no
later than October 1, preferably sooner. All the committee
members in the following list are section writers. See the
responsibilities of a section writer in the next section.
Person Responsibilities
Mary Boelke Packages, Symbols
Skona Brittain Control Structure, Sequences
Kathy Chapman Editor (see list of responsibilities below)
Chapters 1, 3, 5, 7, 8, Glossary
Make up glossary of error terms, get approved by
error, edit, and CLOS committees
Create a proposal for handling language subsets
Sonya Keene Characters, Strings
Gregor Kiczales CLOS
Barry Margolin Arrays, Evaluator, IO, Structures
Bob Mathis Numbers
Larry Masinter Files, Hashtables, Lists, Predicates
Jeff Piazza Declarations
Kent Pitman Chapter 2, Errors, Miscellaneous, Types
Jonathan Rees Chapter 4
Jeff Rosenking Macros, Streams
!
Page 2
Walter van Roggen Program Structure
2 SUMMARY OF MEETINGS
2.1 Meeting 1
A new outline was proposed and accepted:
Chapter 1 - Introduction
Chapter 2 - Objects and Types (the current section 3.1)
Chapter 3 - Object Syntax (the current section 3.2)
Chapter 4 - Evaluation and Compilation (the current sections
2.1, 2.2, and 2.4)
Chapter 5 - Other Topics (the current sections 2.3 and 3.3)
Chapter 6 - Catalog (the current chapter 4)
Chapter 7 - Language syntax summary (the current chapter 5)
Chapter 8 - Language formal semantics (the current chapter 6)
Glossary
A method of delegating responsibility was proposed and accepted.
A summary of the method follows.
The chapters have been EDITED. That means that information
from CLtL has been included. The job of the section writer is to
take over the responsibility for the assigned sections. If there
is a question about a section the writer is responsible for, the
question goes to the writer. After the section has been turned
over to the writer, both the writer and the editor will be making
changes, so the changes have to be coordinated and well marked. A
summary of section writer and editor responsibilities follows.
Responsibilities of the section writer.
1. Get the most recent copies of the assigned material.
2. Find problems, make corrections, mark corrections in original.
Send corrections electronically, or mail them hardcopy to the
editor.
3. Refrain from making any changes while the document is in the
editor's control unless they are specifically requested.
!
Page 3
4. Answer questions about the sections.
5. Notify the committee as soon as you learn that you will not
have the time to help on the editorial committee.
6. Respond to comments, incorporate the comment, or let the
commenter know why it wasn't incorporated. Review response
with editor before responding.
7. Forward comments and your response to the editor so they can
be tracked.
8. Receive comments on your section from the editor and draft
responses.
9. Use the cl-editorial mailing list and other experts in your
area to resolve technical issues.
10. Be prepared to review the entire document after the completion
of each phase.
Responsibilities of the editor:
1. Make sections available to the writers upon request.
2. Refrain from making changes while the document is in the
writer's control.
3. Include X3 issues, CLOS, ...
4. Annotate editorial changes in the source file.
5. Incorporate changes made by the writers into the proper
sections and proliferate those changes through the document if
necessary.
6. Track comments on all sections.
7. Forward comments to the appropriate section writer.
8. Assist in resolving technical issues.
9. Resolve issues of style and format.
Copies of the snapshot of the standard were distributed and
reviewed by small groups. Kathy Chapman will incorporate the
recommendations suggested by the groups except where otherwise
noted.
1. Group 1: current Chapter 2: Jonathan Rees, Dick Gabriel,
Jeff Piazza
!
Page 4
Recommendations:
1. There should be more subsections in this chapter.
2. There should be more detail in the evaluation model.
(Jonathan Rees will guide this effort.)
3. There should be a liaison person who tracks the compiler
committee issues and insures their correct insertion into
this chapter in the standard. (Kathy Chapman is working
with Sandra Loosemore to make sure this happens.)
2. Group 2: current Chapter 3: Barry Margolin, Sonya Keene,
Walter van Roggen, Linda deMicheal
Recommendations:
1. A list of all `tools' that apply to a certain object is to
be supplied after the object description.
2. There should be more sections and subsections, also more
introductory material before each section break. In
particular, there should be a separate section for each
data type. Possible headings would be `Type Hierarchy',
`Type Declarations', data type headings, `Coercion', `Type
Specifiers'.
3. Move paragraphs at the bottom of page 3-3 and the top of
page 3-4 elsewhere?
4. Move the discussion on arguments somewhere else?
5. Clarify the use of the terms type and data type, and be
consistent in their usage.
6. Define the distinction between an object and a true
object.
7. Move Figure 3-4 to earlier in the section.
8. Move print-read consistency rules.
9. Need to distinguish between an object and the printed
representation of an object. (e.g. p. 3-31)
10. Move character ordering information to section where
characters as a data type is described.
11. Move figure 3-9 to earlier in the chapter.
12. Pages 3-35 through 3-39 contain material that needs
clarification or belongs elsewhere.
!
Page 5
13. Correct all numbering schemes for readability.
14. Give an overview of types before giving details.
15. Change the chapter names from `Object Syntax' to
`Read/write Syntax' and `Objects and Types' to `Data
Types'. (This is still under consideration.)
3. Group 3: current Chapters 1 and 4: Jeff Rosenking, Mary
Boelke, Kent Pitman, Skona Brittain
Recommendations:
1. Separate `Definitions' into `Notational Conventions' and
glossary.
2. There is an issue about when function definitions should
be grouped. Will the presence of a good index solve the
problem of finding a function the isn't alphabetically
organized? Listing all functions in the format we are now
using would mean a great many blank pages.
3. Rename `Purpose' to `Description'. This heading will
contain a summary of the tool in the first one or two
sentences. It will also contain all intended aspects of
the tool, but does not necessarily have to include all
fields referenced below it.
4. Leave all fields in; decide on deletion of blank ones
before final review. For example, under Side Effects, the
word `none' should be entered if there are no entries,
whereas, if there are no entries under See Also, that
heading should be deleted.
5. In syntax field and in running text, leave out colons on
keywords.
6. Rename `Errors Signaled' to `Conditions'. This field will
contain all errors.
7. Rephrase the definitions of the fields at the beginning of
Chapter 4.
8. Add `Affected By:' heading. (This is under
consideration.)
2.2 Meeting 2
At this meeting, responsibilities for the various parts of
the standard were designated as follows:
!
Page 6
Chapter 1 - Kathy Chapman
Chapter 2 - Kent Pitman
Chapter 3 - Kathy Chapman
Chapter 4 - Jonathan Rees
Chapter 5 - Kathy Chapman
Chapter 6 - see below
Arrays - Barry Margolin
Characters - Sonya Keene
Control Structure - Skona Brittain
Declarations - Jeff Piazza
Errors - Kent Pitman
Evaluator - Barry Margolin
Files - Larry Masinter
Hashtables - Larry Masinter
IO - Barry Margolin
Lists - Larry Masinter
Macros - Jeff Rosenking
Miscellaneous - Kent Pitman
Numbers - Bob Mathis
Packages - Mary Boelke
Predicates - Larry Masinter
Program Structure - Walter van Roggen
Sequences - Skona Brittain
Streams - Jeff Rosenking
Strings - Sonya Keene
CLOS - Gregor Kiczales
Structures - Barry Margolin
!
Page 7
Symbols - Mary Boelke
Types - Kent Pitman
Chapter 7 - Kathy Chapman
Chapter 8 - Kathy Chapman
∂19-Jul-88 1046 CL-Editorial-mailer just to let you know
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Jul 88 10:46:03 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA03748; Tue, 19 Jul 88 10:45:25 PDT
Message-Id: <8807191745.AA03748@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 19 Jul 88 13:42
To: cl-editorial@sail.stanford.edu
Subject: just to let you know
I have having some logistic trouble moving the standard onto the FTP
machine for your to access.
I will let you know when I have succeeded, but it won't be before Friday.
I will be sending you hardcopies of the parts you are responsible for
at the beginning of next week.
Thanks in advance for your help.
kathy chapman
∂26-Jul-88 0613 CL-Editorial-mailer standard mailing
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 Jul 88 06:13:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA17263; Tue, 26 Jul 88 06:13:03 PDT
Message-Id: <8807261313.AA17263@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 26 Jul 88 09:11
To: cl-editorial@sail.stanford.edu
Subject: standard mailing
I am still having problems making the standard available for FTPing.
Your review hardcopies are in the mail.
Sorry for the delay.
kathy chapman
∂06-Aug-88 0325 CL-Editorial-mailer mailing list change
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Aug 88 03:25:30 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA01415; Sat, 6 Aug 88 03:24:48 PDT
Message-Id: <8808061024.AA01415@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Aug 88 06:23
To: cl-editorial@sail.stanford.edu
Subject: mailing list change
Please add Ellen Golden to cl-editorial.
ellen@stony-brook.scrc.symbolics.com
∂06-Aug-88 0326 CL-Editorial-mailer mailing list change
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Aug 88 03:26:07 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA01426; Sat, 6 Aug 88 03:25:21 PDT
Message-Id: <8808061025.AA01426@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Aug 88 06:24
To: cl-editorial@sail.stanford.edu
Subject: mailing list change
Please remove Sonya Keene from cl-editorial.
∂08-Aug-88 1243 CL-Editorial-mailer CL standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Aug 88 12:43:09 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13098; Mon, 8 Aug 88 12:42:23 PDT
Message-Id: <8808081942.AA13098@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Aug 88 15:38
To: cl-editorial@sail.stanford.edu
Subject: CL standard
Finally I have overcome the logistic problems of getting the standard
on a machine from which you can FTP it.
The username is FTP_USER. The password is FTPPLEASEWORK.
The node is hudson.dec.com.
The first file you should copy is named read-me.txt. It tells you
which other files you will need.
Please don't be silent if you have problems.
Also, you may have noticed that you haven't gotten your standard that
was supposedly mailed 2 weeks ago. Don't worry, it's coming.
kc
∂23-Aug-88 0749 CL-Editorial-mailer standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 23 Aug 88 07:49:26 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06814; Tue, 23 Aug 88 07:48:27 PDT
Message-Id: <8808231448.AA06814@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 23 Aug 88 10:43
To: cl-editorial@sail.stanford.edu
Subject: standard
Would any of you have a problem with my allowing all of X3J13 to access
the standard files now (before I have incorporated your comments)?
kc
∂23-Aug-88 0907 CL-Editorial-mailer standard
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Aug 88 09:07:39 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 23 Aug 88 12:06:18 EDT
Received: by joplin.think.com; Tue, 23 Aug 88 12:06:13 EDT
Date: Tue, 23 Aug 88 12:06:13 EDT
From: gls@Think.COM
Message-Id: <8808231606.AA03828@joplin.think.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 23 Aug 88 10:43 <8808231448.AA06814@decwrl.dec.com>
Subject: standard
From: chapman%aitg.DEC@decwrl.dec.com
Date: 23 Aug 88 10:43
Would any of you have a problem with my allowing all of X3J13 to access
the standard files now (before I have incorporated your comments)?
kc
Fine with me.
--Guy
∂30-Aug-88 0858 CL-Editorial-mailer questions
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88 08:58:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29898; Tue, 30 Aug 88 07:13:36 PDT
Date: Tue, 30 Aug 88 07:13:36 PDT
Message-Id: <8808301413.AA29898@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu
Subject: questions
1. I am changing the wording in section 2.3 of the standard under SYMBOLS
from
"{\datatype Symbols} have the following
components, the first three of which are user-visible.
\beginlist
\itemitem{--} The property list is a {\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
are indicators (no duplicates on the same
property list are allowed)
and whose odd-numbered components are {\word objects}.
Any memory cell acceptable to @Macref[setf] can be used.
The property list of a {\datatype symbol}
may be destructively replaced."
to
"{\datatype Symbols} have the following
components, the first three of which are user-visible.
\beginlist
\itemitem{--} The property list is a {\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
**are symbols (no duplicates on the same**
property list are allowed)
and whose odd-numbered components are {\word objects}.
Any memory cell acceptable to @Macref[setf] can be used.
The property list of a {\datatype symbol}
may be destructively replaced."
Does anyone have a problem with this?
2. In case you didn't notice, I have left out any phrases that go like
"other implementation-dependent bookkeeping actions may be taken ....".
Does anyone have a problem with this?
3. Also, I have not included any information about indentation of comments
in the standard. Is there a problem with this?
kc
∂30-Aug-88 1056 CL-Editorial-mailer Re: questions
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88 10:55:09 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA11616; Tue, 30 Aug 88 10:54:00 PDT
Date: Tue, 30 Aug 88 10:54:00 PDT
Message-Id: <8808301754.AA11616@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: chapman%aitg.DEC@decwrl.dec.com
Subject: Re: questions
1. [defining property list indicators to be symbols]
page 163 of CLtL does say that "a key (called the indicator), which is
typically a symbol,..."
This implies to me that non symbols are allowed as keys, which I believe
is a good thing. However, it doesn't seem to say how keys are supposed
to be compared until you read the description of GET. But that's information
that can be moved around for completeness/clarity.
---Walter
∂30-Aug-88 1350 CL-Editorial-mailer questions
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Aug 88 13:50:27 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 30 Aug 88 16:40:16 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 30 Aug 88 16:47:10 EDT
Date: Tue, 30 Aug 88 16:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: questions
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8808301413.AA29898@decwrl.dec.com>
Message-Id: <19880830204720.8.BARMAR@OCCAM.THINK.COM>
Date: Tue, 30 Aug 88 07:13:36 PDT
From: chapman%aitg.DEC@decwrl.dec.com
1. I am changing the wording in section 2.3 of the standard under SYMBOLS
from
"{\datatype Symbols} have the following
components, the first three of which are user-visible.
\beginlist
\itemitem{--} The property list is a {\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
are indicators (no duplicates on the same
property list are allowed)
and whose odd-numbered components are {\word objects}.
Any memory cell acceptable to @Macref[setf] can be used.
The property list of a {\datatype symbol}
may be destructively replaced."
to
"{\datatype Symbols} have the following
components, the first three of which are user-visible.
\beginlist
\itemitem{--} The property list is a {\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
**are symbols (no duplicates on the same**
property list are allowed)
and whose odd-numbered components are {\word objects}.
Any memory cell acceptable to @Macref[setf] can be used.
The property list of a {\datatype symbol}
may be destructively replaced."
Does anyone have a problem with this?
I do. There is NO rule in Common Lisp that says that property list
indicators must be symbols.
Also, the second sentence in both versions should be deleted. This
section is supposed to be describing symbols, and property lists stored
in arbitrary locations are a completely separate issue (unfortunately,
both CLtL and the Symbolics manuals make this mistake of listing the
functions that operate on arbitrary property lists in the chapter on
symbols).
barmar
∂30-Aug-88 1615 CL-Editorial-mailer questions
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Aug 88 16:15:15 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 30 Aug 88 19:05:22 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 30 Aug 88 19:12:25 EDT
Date: Tue, 30 Aug 88 19:12 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: questions
To: jar@zurich.ai.mit.edu
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: <8808302224.AA00792@void>
Message-Id: <19880830231238.4.BARMAR@OCCAM.THINK.COM>
Date: Tue, 30 Aug 88 18:24:13 edt
From: jar@void.ai.mit.edu (Jonathan Rees)
The first argument to GET must be a symbol (see page 164). Therefore
the only way to store non-symbol indicators would be with (SETF
(SYMBOL-PLIST ..) ...), and the only way to get them would be with
SYMBOL-PLIST. This is silly, of course. If you don't accept this
interpretation that "valid first argument to GET" and "valid
indicator" mean the same thing, or if you think GET should be changed,
you should take it up with the cleanup committee.
The indicator is the SECOND argument to GET. The first argument is the
symbol whose plist is being examined.
barmar
∂31-Aug-88 1459 CL-Editorial-mailer questions
Received: from void (VOID.AI.MIT.EDU) by SAIL.Stanford.EDU with TCP; 31 Aug 88 14:59:46 PDT
Received: by VOID.AI.MIT.EDU; Tue, 30 Aug 88 18:24:13 edt
Date: Tue, 30 Aug 88 18:24:13 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8808302224.AA00792@void>
To: barmar@Think.COM
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 30 Aug 88 16:47 EDT <19880830204720.8.BARMAR@OCCAM.THINK.COM>
Subject: questions
Reply-To: jar@zurich.ai.mit.edu
The first argument to GET must be a symbol (see page 164). Therefore
the only way to store non-symbol indicators would be with (SETF
(SYMBOL-PLIST ..) ...), and the only way to get them would be with
SYMBOL-PLIST. This is silly, of course. If you don't accept this
interpretation that "valid first argument to GET" and "valid
indicator" mean the same thing, or if you think GET should be changed,
you should take it up with the cleanup committee.
∂31-Aug-88 1459 CL-Editorial-mailer questions
Received: from void (VOID.AI.MIT.EDU) by SAIL.Stanford.EDU with TCP; 31 Aug 88 14:59:23 PDT
Received: by VOID.AI.MIT.EDU; Wed, 31 Aug 88 16:16:17 edt
Date: Wed, 31 Aug 88 16:16:17 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8808312016.AA01328@void>
To: barmar@Think.COM
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 30 Aug 88 19:12 EDT <19880830231238.4.BARMAR@OCCAM.THINK.COM>
Subject: questions
Reply-To: jar@zurich.ai.mit.edu
Date: Tue, 30 Aug 88 19:12 EDT
From: Barry Margolin <barmar@Think.COM>
The indicator is the SECOND argument to GET. The first argument is the
symbol whose plist is being examined.
Silly me. I withdraw my previous message. An indicator can be anything.
∂02-Sep-88 2136 CL-Editorial-mailer wording about Symbols
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 21:34:28 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 02 SEP 88 21:23:04 PDT
From: masinter.pa@Xerox.COM
Date: 2 Sep 88 21:21:15 PDT
Subject: wording about Symbols
To: chapman%aitg.dec@declwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <880902-212304-7959@Xerox>
There was a discussion a while back that the wording which implied that symbols
had "components" was misleading, especially when thinking of symbols as
"atomic". I think it might be clearer just to say that symbols "have" a property
list, rather than they have it as a component.
--
On leaving things out: I don't think as a reviewer I can reasonably detect when
things get left out. I think some of the original comments are informative, and
in a few places (although not in this one) an important part of the semantics of
the language. Could at least some indication of the elisions be left in the
draft?
∂06-Sep-88 1348 CL-Editorial-mailer Notation in standard for function argument/value types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88 13:48:04 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 6 Sep 88 16:47:19 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 6 Sep 88 16:43:20 EDT
Date: Tue, 6 Sep 88 16:43 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Notation in standard for function argument/value types
To: cl-editorial@sail.stanford.edu
Message-Id: <19880906204331.8.BARMAR@OCCAM.THINK.COM>
In reviewing sections of the CL draft, I have not been pleased with the
use of English to describe the types of arguments to and values of
functions. Common Lisp provides a language for describing the types of
arguments and values: the FUNCTION declaration. In other language
standards, it is common to use the language-provided function
declaration syntax to describe the library functions, so why not do the
same? For example, COPY-READTABLE would be described with:
(proclaim (function copy-readtable (&optional (or readtable nil)
(or readtable nil))
readtable))
We would still have to use English to describe the default values, but
we would at least formalize the type specifications. Many functions
have complex defaulting rules, so it probably wouldn't be too helpful to
try to formalize them this way. There may also be a few functions with
strange type dependencies between arguments, which can't be described
using the above notation, but these are pretty rare.
A similar notation could be used for variables:
(proclaim (type (integer 2 36) *read-base*))
I'd be willing to enter these changes for the sections I'm responsible
for. What do the rest of the people on the subcommittee think?
barmar
∂06-Sep-88 1414 CL-Editorial-mailer Notation in standard for function argument/value types
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Barry suggests using the FUNCTION declaration style for describing the
types of arguments and values of a function. I think that unless X3J13
adopts a different semantics for the FUNCTION declaration, it would be
unwise to use this notation. You should carefully read the description on
pages 47 and 48 of CLtL to see what I mean.
The problem is that the current definition of FUNCTION type specifiers
is so confusing to average readers that linking this important piece of
information about a function to that confusing model will lead to trouble.
-rpg-
∂06-Sep-88 1450 CL-Editorial-mailer Re: Notation in standard for function argument/value types
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88 14:49:56 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 SEP 88 14:38:14 PDT
Date: 6 Sep 88 14:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Notation in standard for function argument/value types
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Tue, 6 Sep 88 16:43
EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu
Message-ID: <880906-143814-11115@Xerox>
The semantics of the FUNCTION type declaration are the subject of a pending
cleanup issue: there is disagreement in theory and in current practice (that is,
people don't agree what they mean and the implementations that pay attention to
them don't agree either.)
∂06-Sep-88 2131 CL-Editorial-mailer Notation in standard for function argument/value types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88 21:31:26 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 6 Sep 88 18:04:42 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 6 Sep 88 17:55:25 EDT
Date: Tue, 6 Sep 88 17:55 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Notation in standard for function argument/value types
To: Dick Gabriel <RPG@sail.stanford.edu>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <czxPZ@SAIL.Stanford.EDU>
Message-Id: <19880906215531.0.BARMAR@OCCAM.THINK.COM>
Date: 06 Sep 88 1414 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Barry suggests using the FUNCTION declaration style for describing the
types of arguments and values of a function. I think that unless X3J13
adopts a different semantics for the FUNCTION declaration, it would be
unwise to use this notation. You should carefully read the description on
pages 47 and 48 of CLtL to see what I mean.
I think I understand the FUNCTION type specifier, and in fact I believe
that it is just right for this type of thing. If a particular
implementation compatibly extends the domain of a function it will still
be of the type specified in the CL spec, and the current definition of
the FUNCTION type allows this. A FUNCTION declaration doesn't restrict
an implementation, it restricts a caller that is in the scope of the
declaration; in our case, it is a restriction on portable CL programs.
However, it places a requirement on implementations to accept at least
the types specified by the declaration; this is precisely what the
English version currently tries to do.
The problem is that the current definition of FUNCTION type specifiers
is so confusing to average readers that linking this important piece of
information about a function to that confusing model will lead to trouble.
The audience of an ANSI language standard is not average readers. It is
language designers (us), language implementors, and authors of books
intended for average readers. Anyone who can't understand the FUNCTION
type specifier should not be attempting any of those tasks. I agree
that the wording in CLtL is not the best, but I hope we can fix that in
the editing process.
barmar
∂06-Sep-88 2346 CL-Editorial-mailer Re: Notation in standard for function argument/value types
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88 23:46:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 SEP 88 23:44:53 PDT
Date: 6 Sep 88 23:45 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Notation in standard for function argument/value types
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Tue, 6 Sep 88 16:43
EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu
Message-ID: <880906-234453-12009@Xerox>
Actually, we can accept the main point of Barmar's suggestion, which is to use
CL type specifiers instead of English where possible. The function type may have
problems, but you can just say
copy-readtable
from-readtable (or readtable null)
to-readtable (or readtable null)
returns:
readtable
without getting into the function-type-argument-type-semantics hair.
∂07-Sep-88 1017 CL-Editorial-mailer Audience of the Standard
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Barry writes the following:
``The audience of an ANSI language standard is not average readers. It is
language designers (us), language implementors, and authors of books
intended for average readers. Anyone who can't understand the FUNCTION
type specifier should not be attempting any of those tasks. I agree
that the wording in CLtL is not the best, but I hope we can fix that in
the editing process.''
I know what he is getting at, and it might be an appropriate comment at
the stage we're in, but I think it's a bad attitude to take. We really
ought to make this as accessible as we can to as many people as we can.
For example, Will Clinger and I were talking about how we could make
a denotational semantics for Lisp more accessible to average Lisp implementors.
Often an implementor will want to turn to the formal semantics to understand
something that is unclear from the other descriptions. We did not say,
well, someone who hasn't an advanced degree in mathematics should not be
attempting to read this, so why bother. Instead, we talked of how to
ease the reading and understanding woes of denotational semantics.
Average readers, as Barry points out, might be reading user's guides and
textbooks. But when the author of one of these smears a point to make the
reading easier, that average reader will want to go to the source. So why
assume that average readers won't see the document? Good writing and
presentation are needed everywhere, and we cannot legislate that away
because we assume only an elite readership.
-rpg-
∂09-Sep-88 1217 CL-Editorial-mailer type specifiers
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 9 Sep 88 12:17:13 PDT
Received: from csilvax.ucsb.edu
by hub.ucsb.edu (5.59/UCSB-v2)
id AA13982; Fri, 9 Sep 88 12:16:33 PDT
Message-Id: <8809091916.AA13982@hub.ucsb.edu>
Received: from by csilvax.ucsb.CSNET (5.51) id AA07642; Fri, 9 Sep 88 12:16:27 PDT
Date: Fri, 9 Sep 88 12:16:27 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Fri, 9 Sep 88 12:16:27 PDT
To: CL-Editorial@SAIL.Stanford.edu
Subject: type specifiers
Cc: skona%csilvax@hub.ucsb.edu
I think that Barmar's suggestion, as modified by Larry, would be
a great improvement over the English descriptions.
But if we are going to incorporate it into Phase 1 revisions, we
better decide quickly.
We probably should pick a precise format/style for it, so Kathy
can keep the changes consistent among the chapters.
On second thought, I think we should postpone the change until
Phase 2.
∂12-Sep-88 0843 CL-Editorial-mailer committee
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 08:42:59 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25762; Mon, 12 Sep 88 08:41:43 PDT
Message-Id: <8809121541.AA25762@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 11:38
To: cl-editorial@sail.stanford.edu
Subject: committee
I am making plans for an editorial committee meeting on 10/10
beginning at 11:30AM and lasting until 3:30PM. The location
has not been determined. Please let me know if you have problems
with this date or time.
kc
∂12-Sep-88 1037 CL-Editorial-mailer Issue: CLOS-:initform-typographical-errors
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Issue: CLOS-:initform-typographical-errors
Category: Technical
Edit History: Version 1, Dick Gabriel, 9/12/88
Problem Description:
page 1-35 of the CLOS specification (88-002R) has two occurrences of
the name initform that ought to be :initform:
\item{\bull} Supplying a default initial value form for a slot. A
default initial value form for a slot is defined by using the {\bf
:initform} slot option to {\bf defclass}. If no initialization
argument associated with that slot is given as an argument to {\bf
make-instance} or is defaulted by {\bf :default-initargs}, this
default initial value form is evaluated in the lexical environment of
the {\bf defclass} form that defined it, and the resulting value is
stored in the slot. The {\bf initform} form for a local slot may be
used when creating an instance, when updating an instance to conform
to a redefined class, or when updating an instance to conform to the
definition of a different class. The {\bf initform} form for a shared
slot may be used when defining or re-defining the class.
page 1-44 of the CLOS specification has one occurrence of
the name initform that ought to be :initform:
Methods for {\bf update-instance-for-redefined-class} may be defined
to specify actions to be taken when an instance is updated. If only
{\bf :after} methods for {\bf update-instance-for-redefined-class} are
defined, they will be run after the system-supplied primary method for
initialization and therefore will not interfere with the default
behavior of {\bf update-instance-for-redefined-class}. Because no
initialization arguments are passed to {\bf
update-instance-for-redefined-class} when it is called by the system,
the {\bf initform} forms for slots that are filled by {\bf :before}
methods for {\bf update-instance-for-redefined-class} will not be
evaluated by {\bf shared-initialize}.
page 1-47 of the CLOS specification has one occurrence of
the name initform that ought to be :initform:
Methods for {\bf update-instance-for-different-class} may be defined
to specify actions to be taken when an instance is updated. If only
{\bf :after} methods for {\bf update-instance-for-different-class} are
defined, they will be run after the system-supplied primary method for
initialization and will not interfere with the default behavior of
{\bf update-instance-for-different-class}. Because no initialization
arguments are passed to {\bf update-instance-for-different-class} when
it is called by {\bf change-class}, the {\bf initform} forms for slots
that are filled by {\bf :before} methods for {\bf
update-instance-for-different-class} will not be evaluated by {\bf
shared-initialize}.
Proposal:
Insert : as indicated:
page 1-35
\item{\bull} Supplying a default initial value form for a slot. A
default initial value form for a slot is defined by using the {\bf
:initform} slot option to {\bf defclass}. If no initialization
argument associated with that slot is given as an argument to {\bf
make-instance} or is defaulted by {\bf :default-initargs}, this
default initial value form is evaluated in the lexical environment of
the {\bf defclass} form that defined it, and the resulting value is
stored in the slot. The {\bf :initform} form for a local slot may be
used when creating an instance, when updating an instance to conform
to a redefined class, or when updating an instance to conform to the
definition of a different class. The {\bf :initform} form for a shared
slot may be used when defining or re-defining the class.
page 1-44
Methods for {\bf update-instance-for-redefined-class} may be defined
to specify actions to be taken when an instance is updated. If only
{\bf :after} methods for {\bf update-instance-for-redefined-class} are
defined, they will be run after the system-supplied primary method for
initialization and therefore will not interfere with the default
behavior of {\bf update-instance-for-redefined-class}. Because no
initialization arguments are passed to {\bf
update-instance-for-redefined-class} when it is called by the system,
the {\bf :initform} forms for slots that are filled by {\bf :before}
methods for {\bf update-instance-for-redefined-class} will not be
evaluated by {\bf shared-initialize}.
page 1-47
Methods for {\bf update-instance-for-different-class} may be defined
to specify actions to be taken when an instance is updated. If only
{\bf :after} methods for {\bf update-instance-for-different-class} are
defined, they will be run after the system-supplied primary method for
initialization and will not interfere with the default behavior of
{\bf update-instance-for-different-class}. Because no initialization
arguments are passed to {\bf update-instance-for-different-class} when
it is called by {\bf change-class}, the {\bf :initform} forms for slots
that are filled by {\bf :before} methods for {\bf
update-instance-for-different-class} will not be evaluated by {\bf
shared-initialize}.
Rationale: Although not strictly necessary, :initform is used everywhere
else in the document.
Current Practice:
Cost to Implementors:
Cost to Users:
Cost of Non-adoption: Readers will be confused.
Benefits: We will be considered more careful editors.
Discussion: RPG will edit the changes in the original sources before
they are handed over to this committee.
∂19-Sep-88 1439 CL-Editorial-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 14:38:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03479g; Mon, 19 Sep 88 13:37:14 PST
Received: by bhopal id AA14744g; Mon, 19 Sep 88 14:36:41 PDT
Date: Mon, 19 Sep 88 14:36:41 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809192136.AA14744@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, GLS@Think.com,
CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Mon, 12 Sep 88 20:25 EDT <19880913002519.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
re: Proposal (HASH-TABLE-KEY-MODIFICATION:SPECIFY):
. . .
I fear this is far too vague to be a cleanup proposal, however well-
motivated it may have been. Indeed, there was a discussion of this topic
on Common-Lisp@SU-AI about a year ago (as well as a few related msgs quite
recently), but the upshot of all the discussion was merely to "enlighten"
more of the community about the techniques of hashing in general. I think
we should limit our efforts in this arena at giving advice to editors
(such as Steele, and Chapman, etc.) on how to explain the consequences of
some typical hashing techniques.
First, there is no generally agreed-upon notion of what a "component" is;
so the part where you say:
In EQ and EQL hash tables, components of a key may be freely modified
with no effect on the table.
In EQUAL hash tables, it is an error to modify a component of a key.
isn't saying anything usable; or if it is, then it is something already
understood via channels outside this proscription. Furthermore, it could
bog us down for months if we tried to specify "component" exactly. For
example, is the bit-field (byte 3 5) of a fixnum X a "component" of X?
Second, the "rule":
If implementations define additional acceptable values for the :TEST
argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
a component of a key if and only if that component affects the test
function. If that component cannot affect the test function, the hash
table's operation must not be affected by modifying the component.
is completely inadequate. You might as well say that it is an error to
modify the components of list elements for any list that is passed to a
sequence function with a :test argument of EQUAL. What you probably meant
to say, in the hash-table context, is:
... it is an error to modify an object used as key in a hash table
iff such modification affects either (1) the outcome of equivalence
test used by the hash-table, or (2) the structure of the collision
chains built up in the hash table [note that SXHASH, or a substitute
therefor, may be involved in the structure of collision chains].
[There might have to be a line saying that the :test component of a hash-
table is always an equivalence relation.] However, CLtL neither specifies
that hash-tables must use some "collision chain" technique -- alists appear
to be a fully conforming implementation (albeit sloooow) -- nor does is even
specify that any such collision tecnhique must be based on the output of
SXHASH. About the most it says is that hashing should be "fast".
Unfortunately, nowhere does the discussion of HASH-TABLE-KEY-MODIFICATION
even mention collision chains.
An implementational note *might* be worth mentioning in the document
standard about how the historical intent of EQ/EQL tables was in fact
to limit the information obtained from an object to merely the pointer
itself (i.e., it's address), and that this usually meant faster hashing
(in MacLisp, for example). But with the spread of copying GC's (stop-
and-copy, generational, etc) this kind of dependency limitation forces
some very odd behaviour on the memory-management subsystem, such as the
need for rehashing after GC's, etc. I really know of cases where an EQL
table was grossly slower than an EQUAL table, simply because it forced so
much more attention from the memory-management subsystem.
Typically, only very "introspective" code needs to know whether, say, two
strings are EQL rather EQUAL; and very often even experienced users make
the mistake of thinking that EQ means speed and EQUAL means sloth.
Certainly no one using Common Lisp should prefer an EQ/EQL table over
an EQUAL one, unless he is actually concerned with the implementational
identity of objects [such as in system code doing circularity checks,
or "constants" coalescing, or macromemo-izing, etc.].
I think the gist of these last two paragraphs is something that the
standards editors could try to work into the next chapter on Hash-Tables
(and possibly something about "collision chains" being a frequent part
of hash-tables). This would be preferable to having the cleanup sub-
committee try to solve the unsolvable problem of anticipating every
possible consequence of every possible implementation technique for
hash-tables.
-- JonL --
∂19-Sep-88 1505 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:05:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 15:02:27 PDT
Date: 19 Sep 88 15:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Mon, 19 Sep 88 14:36:41
PDT
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU,
GLS@Think.com, CL-Editorial@SAIL.STANFORD.EDU
Message-ID: <880919-150227-2389@Xerox>
My immediate reaction to your message was that it was a hasty disqualification
of an otherwise valid issue for the cleanup committee to address.
Certainly the issue needs to be addressed. If Kathy things it is reasonable to
do so within the scope of the editorial board, I'm happy to allow it to be
addressed there.
However, it does seem like an issue that can be well-specified without resorting
to a discussion of copying garbage collectors and collision chains in the
specification.
∂19-Sep-88 1542 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:41:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461963; Mon 19-Sep-88 18:39:45 EDT
Date: Mon, 19 Sep 88 18:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU, GLS@Think.com, CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: <8809192136.AA14744@bhopal>
Message-ID: <19880919223934.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Sep 88 14:36:41 PDT
From: Jon L White <jonl@lucid.com>
....
First, there is no generally agreed-upon notion of what a "component" is;
so the part where you say:
In EQ and EQL hash tables, components of a key may be freely modified
with no effect on the table.
In EQUAL hash tables, it is an error to modify a component of a key.
isn't saying anything usable; or if it is, then it is something already
understood via channels outside this proscription.
It's true that "component" is a vague notion. As elaborated on later in
the proposal, "component" should be defined in terms of the test function.
Maybe this initial vague language should just be abandoned.
Furthermore, it could
bog us down for months if we tried to specify "component" exactly. For
example, is the bit-field (byte 3 5) of a fixnum X a "component" of X?
Who cares, since Common Lisp does not provide any way to modify fixnums.
Second, the "rule":
If implementations define additional acceptable values for the :TEST
argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
a component of a key if and only if that component affects the test
function. If that component cannot affect the test function, the hash
table's operation must not be affected by modifying the component.
is completely inadequate. You might as well say that it is an error to
modify the components of list elements for any list that is passed to a
sequence function with a :test argument of EQUAL.
That's precisely what I would have said, if sequence functions were
permitted to create auxiliary data structures that encache information
about their arguments from one call to the next. Since they are not
(although this is only implied by CLtL), there is no need to impose
such a restriction on their callers.
What you probably meant
to say, in the hash-table context, is:
... it is an error to modify an object used as key in a hash table
iff such modification affects either (1) the outcome of equivalence
test used by the hash-table, or (2) the structure of the collision
chains built up in the hash table [note that SXHASH, or a substitute
therefor, may be involved in the structure of collision chains].
[There might have to be a line saying that the :test component of a hash-
table is always an equivalence relation.] However, CLtL neither specifies
that hash-tables must use some "collision chain" technique -- alists appear
to be a fully conforming implementation (albeit sloooow) -- nor does is even
specify that any such collision tecnhique must be based on the output of
SXHASH. About the most it says is that hashing should be "fast".
Unfortunately, nowhere does the discussion of HASH-TABLE-KEY-MODIFICATION
even mention collision chains.
I vehemently disagree with this, and I think you're being completely
wrong-headed. The point of the proposal was to state what are the
requirements on Common Lisp programs so that they will be portable
to all implementations of hash tables. The internal details of hash
tables in some particular implementation are not relevant; furthermore,
discussing them can only mislead users into writing non-portable
programs. What I meant to say was precisely what I did say. I agree
that an editor could find more precise language than "affect the
test function" by which I mean "change the answer returned by the
test function."
An implementational note *might* be worth mentioning in the document
standard about how the historical intent of EQ/EQL tables was in fact
to limit the information obtained from an object to merely the pointer
itself (i.e., it's address), and that this usually meant faster hashing
(in MacLisp, for example). But with the spread of copying GC's (stop-
and-copy, generational, etc) this kind of dependency limitation forces
some very odd behaviour on the memory-management subsystem, such as the
need for rehashing after GC's, etc. I really know of cases where an EQL
table was grossly slower than an EQUAL table, simply because it forced so
much more attention from the memory-management subsystem.
Typically, only very "introspective" code needs to know whether, say, two
strings are EQL rather EQUAL; and very often even experienced users make
the mistake of thinking that EQ means speed and EQUAL means sloth.
Certainly no one using Common Lisp should prefer an EQ/EQL table over
an EQUAL one, unless he is actually concerned with the implementational
identity of objects [such as in system code doing circularity checks,
or "constants" coalescing, or macromemo-izing, etc.].
I think the gist of these last two paragraphs is something that the
standards editors could try to work into the next chapter on Hash-Tables
(and possibly something about "collision chains" being a frequent part
of hash-tables).
I agree that it might be interesting to have a book that discusses the
performance tradeoffs in hash tables. I don't think that has anything to
do with the issue at hand, which is to define what characteristics of hash
tables may or may not be assumed by portable programs.
This would be preferable to having the cleanup sub-
committee try to solve the unsolvable problem of anticipating every
possible consequence of every possible implementation technique for
hash-tables.
If you thought that's what the HASH-TABLE-KEY-MODIFICATION issue was
about, you misunderstood it. It's about defining whether portable
programs may or may not perform side effects on objects used as
keys of hash tables, and which side-effects can be performed. I
can see it needs to be written up in a form that is less easy
to misunderstand. If I have time, which is not too likely, I'll
do that, otherwise I'll just forget it.
∂28-Sep-88 1344 CL-Editorial-mailer [Robert S. Boyer <boyer@CLI.COM>: Clean Up]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:44:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 13:39:55 PDT
Date: 28 Sep 88 13:40 PDT
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Clean Up]
To: cl-editorial@sail.stanford.edu
Reply-to: boyer@cli.com
Message-ID: <880928-133955-1558@Xerox>
----- Begin Forwarded Messages -----
Return-Path: <boyer@CLI.COM>
Received: from CLI.COM ([10.8.0.62]) by Xerox.COM ; 28 SEP 88 13:01:55 PDT
Received: by CLI.COM (4.0/1); Wed, 28 Sep 88 14:59:46 CDT
Date: Wed, 28 Sep 88 14:59:46 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8809281959.AA13560@CLI.COM>
To: masinter.pa
Subject: Clean Up
Thanks very much!
I hope that the cleanup committee or some other part of the Common
Lisp official definition mechanism will publish a little example
system of several files and packages that exercises the PISERUI stuff,
a template for the rest of us perhaps to follow. A good example is
sometimes worth as much as a specification, and it is something that
you can show to implementors, if it breaks in their implementation,
and say "You are not doing it right." Sometimes specifications have
multiple interpretations.
Bob
----- End Forwarded Messages -----
∂28-Sep-88 1442 CL-Editorial-mailer as if you haven't got enough to review
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 14:41:52 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25606; Wed, 28 Sep 88 14:40:15 PDT
Message-Id: <8809282140.AA25606@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Sep 88 17:31
To: cl-editorial@sail.stanford.edu, POPA%TOWNS.DEC@decwrl.dec.com,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com,
VANROGGEN%aitg.DEC@decwrl.dec.com
Subject: as if you haven't got enough to review
Thanks to all of you who have mailed your comments on the standard.
I will wait for all comments to come in before making the complete
list of comments and corrections organized by chapter available.
Following is the error terminology I (and others) are proposing
should be adopted and incorporated into the standard. I would like
to make this available to X3 as a whole, but would rather wait
until you all have had a chance to review and comment. I would like
to have all your comments before the October meeting so we as a
committee will be able to make a recommendation to X3.
Thanks for your help.
kc
Condition Terminology
September, 1988
Edited by Kathy Chapman, Kent Pitman, Walter Van Roggen
!
Page 2
1 INTRODUCTION
Common Lisp constructs are described in the forthcoming
standard in terms of their behavior in "situations" during which
they are intended to be used (see "Description" and
"Environment/Evaluation" parts of each construct specification),
and in all other "situations" (see "Conditions" part of
specification).
A "situation" is the evaluation of an expression in some
specific context. A "condition", represented by a condition
object, is a situation which has been detected. Some types of
conditions are predefined by the Common Lisp system, and all types
of conditions are subtypes of type CONDITION, i.e. (typep c
'condition) is true if and only if C is a condition. An "error"
is a condition in which normal program execution may not continue
without some form of intervention (either interactively by the
user or under some sort of program control).
"Signalling" is the process by which a situation is announced
by a program and SIGNAL is a mechanism by which such announcement
is done. ERROR and CERROR are also used to signal errors.
Signalling an error has no side-effect on the condition associated
with the error, and there is no dynamic state contained in a
condition object. The interactive interface for signalling is
implementation-dependent.
The process of signalling involves the search for and
invocation of a handler, which is a function of one argument (the
condition) that attempts to deal with the situation. Handlers are
established dynamically using HANDLER-BIND or abstractions built
on HANDLER-BIND such as HANDLER-CASE and IGNORE-ERRORS.
IGNORE-ERRORS is used to inhibit entry to the debugger when all
errors are detected, while HANDLER-CASE is used to perform
specified actions when the specified situations occur. If a
handler is found, it may either handle the situation by performing
some non-local transfer of control or "decline" by failing to
perform a non-local transfer of control. If it declines, other
handlers are sought. If no handler is found and the error was
signalled by ERROR or CERROR, the debugger is entered with no
context change.
The debugger prints the description of the situation
represented by the error being signalled along with contextual
information perhaps including information such as which function
detected the error. The debugger should prefix all lines in a
multiline condition message with the character or indentation used
in the first of the lines of the message. The debugger allows
interactive examination or modification of the state of the
program and restarting from the situation.
The condition object given to the handler is created
explicitly by an operation such as MAKE-CONDITION or implicitly by
an operation such as SIGNAL. The handler is executed in the
dynamic context of the program which has invoked it, except that
!
Page 3
the set of available condition handlers will have been rebound to
the value that was active at the time the condition handler was
made active.
2 TERMINOLOGY
Situations in which errors might, should, or must be
signalled are referred to in the standard. The wording used to
describe such situations is intended to have precise formal
meaning. The following list is a glossary of those meanings.
- A VALID PROGRAM
is a program whose code adheres to the requirements of
conforming code listed as follows:
- Conforming code shall not use any constructions that are
prohibited by the standard.
- Conforming code shall not depend on extensions included in
an implementation.
- Conforming code shall not use any extension included in an
implementation.
- A SAFE SITUATION
is a situation in which interpreted code, or code
compiled with the safest optimization level is run.
- AN UNSAFE SITUATION
is a situation in which code is run with lower safety
levels.
- AN ERROR "IS SIGNALLED"
means that
- If this situation occurs, the error will be signalled, in
both safe and unsafe situations.
- Valid programs may rely on the fact that the error will be
signalled in both safe and unsafe situations.
- Every implementation is required to detect the error in
both safe and unsafe situations.
For example, "an `error is signalled' if UNEXPORT is
given a symbol not accessible in the current package."
!
Page 4
- AN ERROR "SHOULD BE SIGNALLED"
means that
- If this situation occurs, the error will be signalled in
safe situations but may not be signalled in unsafe ones.
- Valid programs may not rely on the fact that the error
will be signalled.
- Every implementation is required to detect the error at
least in safe situations.
- When the error is not signalled, the "consequences are
undefined" (see below).
In summary, the situation which has been identified as an
error is illegal in all implementations, but some
implementations do not actually detect the situation.
For example, "an error `should be signalled' if ENDP is
given a non-list argument."
- THE "CONSEQUENCES ARE UNDEFINED"
means that
- If this situation occurs, the consequences are
unpredictable. The consequences may range from harmless
to fatal.
- Implementations are allowed to detect this situation and
signal an error, but no implementation is required to
detect the situation.
- No valid program may depend on the effects of this
situation, and all valid programs are required to treat
the effects of this situation as unpredictable.
- In places where the words "must", "must not" or "may not"
are used, then "the consequences are undefined" if the
stated requirement is not met, and no specific consequence
is explicitly stated.
There are two principal reasons why this language permits
a situation to have an undefined consequence rather than
requiring an error to be signalled:
- Detecting the situation might be prohibitively expensive
in some or all implementations.
!
Page 5
- The situation can be implemented as an extension.
For example, "the `consequences are undefined' is there
is an attempt to redefine the name of a special form."
- THE "RETURN VALUES ARE UNDEFINED"
means that only the number and nature of the return
values of a construct are not well defined but any side-effect
and transfer-of-control behavior is well defined.
For example, if the return values of some function F are
undefined, then an expression such as (length (list (F))) is
still well-defined because it does not rely on any particular
aspect of the value or values returned by F.
- THE "CONSEQUENCES ARE UNSPECIFIED"
means that
- The consequences of this situation are not specified in
the standard, but are will not, by themselves, cause
execution to abnormally terminate.
- Implementations are allowed to specify the consequences of
this situation.
- No portable program can depend on the consequences of this
situation, and all portable programs are required to treat
the situation as unpredictable but harmless.
For example, "if the second argument to SHARED-INITIALIZE
specifies a name that does not correspond to any slots
accessible in the instance, the `consequences are
unspecified.'"
- "IMPLEMENTATIONS MAY BE EXTENDED" TO COVER THIS SITUATION
means that an implementation is free to treat the
situation in ANY ONE of the following ways.
1. When the situation occurs, an error is signalled at least
in safe situations,
OR
2. When the situation occurs, the "consequences are
undefined",
OR
!
Page 6
3. When the situation occurs, the consequences are defined
and specified.
Also, no portable program can depend on the consequences
of this situation, and all portable programs are required to
treat the consequences of the situation as undefined.
For example, "`implementations may be extended' to define
other type specifiers to have a corresponding class."
- IMPLEMENTATIONS ARE "FREE TO EXTEND THE SYNTAX"
means that in this situation
- Implementations are allowed to define unambiguous
extensions to the syntax of the construct being described.
- No portable program can depend on this extension, all
portable programs are required to treat the syntax as
meaningless.
The standard may disallow certain extensions while
allowing others.
For example, "no `implementation is free to extend the
syntax' of DEFCLASS."
- A "WARNING IS ISSUED"
means that
- If this situation occurs, a warning is issued, as
described in WARN, in both safe and unsafe situations.
- Valid programs may rely on the fact that a warning will be
issued in both safe and unsafe situations.
- Every implementation is required to detect this situation
in both safe and unsafe situations.
For example, "a `warning is issued' by the compiler if a
declaration specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
- A "WARNING SHOULD BE ISSUED"
means that
- If this situation occurs, a warning will be issued at
least in safe situations.
!
Page 7
- Valid programs may not rely on the fact that a warning
will be issued.
- Every implementation is required to detect such a
situation at least in safe situations.
For example, "a warning `should be issued' by a compiler
if a variable declared to be ignored is ever referred to or is
also declared special, or if a variable is lexical, never
referred to, and not declared to be ignored." (see Chapter 9,
CLtL)
∂28-Sep-88 1707 CL-Editorial-mailer as if you haven't got enough to review
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 17:07:13 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 28 Sep 88 20:06:58 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 28 Sep 88 20:03:51 EDT
Date: Wed, 28 Sep 88 20:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: as if you haven't got enough to review
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, POPA%TOWNS.DEC@decwrl.dec.com,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com,
VANROGGEN%aitg.DEC@decwrl.dec.com
In-Reply-To: <8809282140.AA25606@decwrl.dec.com>
Message-Id: <19880929000421.5.BARMAR@OCCAM.THINK.COM>
Date: 28 Sep 88 17:31
From: chapman%aitg.DEC@decwrl.dec.com
- AN UNSAFE SITUATION
is a situation in which code is run with lower safety
levels.
This should be "code compiled with lower safety levels is run."
- AN ERROR "SHOULD BE SIGNALLED"
I'm not crazy about this particular terminology. I prefer something
somewhat less forceful than "should", such as "might" or "may". But I'm
not adamant about it.
- THE "CONSEQUENCES ARE UNDEFINED"
- In places where the words "must", "must not" or "may not"
are used, then "the consequences are undefined" if the
stated requirement is not met, and no specific consequence
is explicitly stated.
I think this should also mention that this includes various implicit
requirements. For example, where the standard specifies the number and
types of arguments of a function, the "consequences are undefined" if
such specifications are not met (in the absence of more specific
language in a particular case).
There are two principal reasons why this language permits
a situation to have an undefined consequence rather than
requiring an error to be signalled:
...
- The situation can be implemented as an extension.
If this is the case, then what is the difference between "CONSEQUENCES
ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
- THE "CONSEQUENCES ARE UNSPECIFIED"
means that
- The consequences of this situation are not specified in
the standard, but are will not, by themselves, cause
execution to abnormally terminate.
"are will" should be "will".
- Implementations are allowed to specify the consequences of
this situation.
- No portable program can depend on the consequences of this
situation, and all portable programs are required to treat
the situation as unpredictable but harmless.
I also don't care for this particular term. "Unspecified" and
"undefined" are too similar in meaning. How about "consequences are
undefined but benign"?
The standard may disallow certain extensions while
allowing others.
For example, "no `implementation is free to extend the
syntax' of DEFCLASS."
I maintain that any such prohibition is meaningless, or at least
unenforceable. How does this differ from "the consequences are
undefined if DEFCLASS is invoked with syntax other than that specified
in the standard"? In both cases, it means that a portable program may
not depend on the behavior. What business do we have constraining how
an implementation deals with nonportable programs?
If you want to constrain implementations, it should be done with a
requirement rather than a prohibition. For instance, "an 'error is
signalled' if DEFCLASS is invoked with syntax not conforming to this
specification". This prevents syntax extensions because it would break
a portable program that relies on the error being signalled.
- A "WARNING IS ISSUED"
means that
- If this situation occurs, a warning is issued, as
described in WARN, in both safe and unsafe situations.
- Valid programs may rely on the fact that a warning will be
issued in both safe and unsafe situations.
- Every implementation is required to detect this situation
in both safe and unsafe situations.
For example, "a `warning is issued' by the compiler if a
declaration specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
This doesn't say what the results are in such situations.
- A "WARNING SHOULD BE ISSUED"
means that
- If this situation occurs, a warning will be issued at
least in safe situations.
- Valid programs may not rely on the fact that a warning
will be issued.
- Every implementation is required to detect such a
situation at least in safe situations.
For example, "a warning `should be issued' by a compiler
if a variable declared to be ignored is ever referred to or is
also declared special, or if a variable is lexical, never
referred to, and not declared to be ignored." (see Chapter 9,
CLtL)
Both "warning" examples only mention warnings issued by the compiler.
In that case, what is the distinction between safe and unsafe
situations? The definitions of "safe" and "unsafe" specify "when code
is run"; is there any situation in which a warning is/should be issued
at run time?. At compile time the only code that is run is the compiler
itself (which I would assume is generally compiled with the lowest
safety level before being shipped to customers) and any macros used in
the program (and any implementation-supplied macros will also probably
be compiled with lowest safety, and there is no way for portable,
user-written macros to access the safety level), but I don't think this
section is referring to either of them.
Also, what does it mean for a program to "rely on the fact that a
warning will be issued"? The only way I know of to even DETECT that a
warning was issued is to redirect *ERROR-OUTPUT* to a file or string and
then see whether it contains anything after the operation.
barmar
∂29-Sep-88 1220 CL-Editorial-mailer re: barmar comments on error paper
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 12:20:00 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08007; Thu, 29 Sep 88 12:18:24 PDT
Message-Id: <8809291918.AA08007@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 29 Sep 88 15:16
To: cl-editorial@sail.stanford.edu, DJAHANDARI%TOWNS.DEC@decwrl.dec.com,
POPA%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com
Subject: re: barmar comments on error paper
> - AN UNSAFE SITUATION
>
> is a situation in which code is run with lower safety
> levels.
>
>This should be "code compiled with lower safety levels is run."
Done.
> - AN ERROR "SHOULD BE SIGNALLED"
>
>I'm not crazy about this particular terminology. I prefer something
>somewhat less forceful than "should", such as "might" or "may". But I'm
>not adamant about it.
My interpretation: `might' or `may' are words a user needs to hear
in this situation; `should' is a word an implementer should see. I know
this isn't an implementation guide, but it's more of that than it is
a user's guide; thus the choice of words makes sense to me.
> - THE "CONSEQUENCES ARE UNDEFINED"
>
> - In places where the words "must", "must not" or "may not"
> are used, then "the consequences are undefined" if the
> stated requirement is not met, and no specific consequence
> is explicitly stated.
>
>I think this should also mention that this includes various implicit
>requirements. For example, where the standard specifies the number and
>types of arguments of a function, the "consequences are undefined" if
>such specifications are not met (in the absence of more specific
>language in a particular case).
Actually the case you mention will be explicit in the standard, not
implicit. Do you have other examples of implicit requirements?
> There are two principal reasons why this language permits
> a situation to have an undefined consequence rather than
> requiring an error to be signalled:
>
> ...
>
> - The situation can be implemented as an extension.
>
>If this is the case, then what is the difference between "CONSEQUENCES
>ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
The definitions of these two phrases are different, one just happens to
indirectly refer to the other.
> - THE "CONSEQUENCES ARE UNSPECIFIED"
>
> means that
>
> - The consequences of this situation are not specified in
> the standard, but are will not, by themselves, cause
> execution to abnormally terminate.
>
>"are will" should be "will".
Done.
> - Implementations are allowed to specify the consequences of
> this situation.
>
> - No portable program can depend on the consequences of this
> situation, and all portable programs are required to treat
> the situation as unpredictable but harmless.
>I also don't care for this particular term. "Unspecified" and
>"undefined" are too similar in meaning. How about "consequences are
>undefined but benign"?
Instead of "CONSEQUENCES ARE UNSPECIFIED"?
> The standard may disallow certain extensions while
> allowing others.
>
> For example, "no `implementation is free to extend the
> syntax' of DEFCLASS."
>
>I maintain that any such prohibition is meaningless, or at least
>unenforceable. How does this differ from "the consequences are
>undefined if DEFCLASS is invoked with syntax other than that specified
>in the standard"? In both cases, it means that a portable program may
>not depend on the behavior. What business do we have constraining how
>an implementation deals with nonportable programs?
>If you want to constrain implementations, it should be done with a
>requirement rather than a prohibition. For instance, "an 'error is
>signalled' if DEFCLASS is invoked with syntax not conforming to this
>specification". This prevents syntax extensions because it would break
>a portable program that relies on the error being signalled.
I agree, but would like to hear from the CLOSers about why a prohibition
rather than a requirement was used in this case.
> - A "WARNING IS ISSUED"
>
> means that
>
> - If this situation occurs, a warning is issued, as
> described in WARN, in both safe and unsafe situations.
>
> - Valid programs may rely on the fact that a warning will be
> issued in both safe and unsafe situations.
>
> - Every implementation is required to detect this situation
> in both safe and unsafe situations.
>
> For example, "a `warning is issued' by the compiler if a
> declaration specifier is not one of those defined in Chapter 9
> of CLtL and has not been declared in a DECLARATION
> declaration."
>
>This doesn't say what the results are in such situations.
Which results? which situation?
>
> - A "WARNING SHOULD BE ISSUED"
>
> means that
>
> - If this situation occurs, a warning will be issued at
> least in safe situations.
>
> - Valid programs may not rely on the fact that a warning
> will be issued.
>
> - Every implementation is required to detect such a
> situation at least in safe situations.
>
>
> For example, "a warning `should be issued' by a compiler
> if a variable declared to be ignored is ever referred to or is
> also declared special, or if a variable is lexical, never
> referred to, and not declared to be ignored." (see Chapter 9,
> CLtL)
>
>Both "warning" examples only mention warnings issued by the compiler.
>In that case, what is the distinction between safe and unsafe
>situations? The definitions of "safe" and "unsafe" specify "when code
>is run"; is there any situation in which a warning is/should be issued
>at run time?. At compile time the only code that is run is the compiler
>itself (which I would assume is generally compiled with the lowest
>safety level before being shipped to customers) and any macros used in
>the program (and any implementation-supplied macros will also probably
>be compiled with lowest safety, and there is no way for portable,
>user-written macros to access the safety level), but I don't think this
>section is referring to either of them.
Currently in CLtL the only time warnings are mentioned is in conjunction
with the compiler (did I miss something?). However, is there a problem
with generalizing warnings?
>Also, what does it mean for a program to "rely on the fact that a
>warning will be issued"? The only way I know of to even DETECT that a
>warning was issued is to redirect *ERROR-OUTPUT* to a file or string and
>then see whether it contains anything after the operation.
Sounds like you answered your own question. Is there better wording?
kc
∂29-Sep-88 1404 CL-Editorial-mailer re: barmar comments on error paper
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 14:03:15 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 29 Sep 88 16:55:56 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 29 Sep 88 16:59:54 EDT
Date: Thu, 29 Sep 88 17:00 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: re: barmar comments on error paper
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, DJAHANDARI%TOWNS.DEC@decwrl.dec.com,
POPA%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com
In-Reply-To: <8809291918.AA08007@decwrl.dec.com>
Message-Id: <19880929210023.4.BARMAR@OCCAM.THINK.COM>
Date: 29 Sep 88 15:16
From: chapman%aitg.DEC@decwrl.dec.com
> - THE "CONSEQUENCES ARE UNDEFINED"
>
> - In places where the words "must", "must not" or "may not"
> are used, then "the consequences are undefined" if the
> stated requirement is not met, and no specific consequence
> is explicitly stated.
>
>I think this should also mention that this includes various implicit
>requirements. For example, where the standard specifies the number and
>types of arguments of a function, the "consequences are undefined" if
>such specifications are not met (in the absence of more specific
>language in a particular case).
Actually the case you mention will be explicit in the standard, not
implicit. Do you have other examples of implicit requirements?
If I think of any I'll let you know.
> There are two principal reasons why this language permits
> a situation to have an undefined consequence rather than
> requiring an error to be signalled:
>
> ...
>
> - The situation can be implemented as an extension.
>
>If this is the case, then what is the difference between "CONSEQUENCES
>ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
The definitions of these two phrases are different, one just happens to
indirectly refer to the other.
Please explain the difference. Describe a situation where one is true
yet the other isn't.
> - THE "CONSEQUENCES ARE UNSPECIFIED"
>
>I also don't care for this particular term. "Unspecified" and
>"undefined" are too similar in meaning. How about "consequences are
>undefined but benign"?
Instead of "CONSEQUENCES ARE UNSPECIFIED"?
Yes.
> The standard may disallow certain extensions while
> allowing others.
>
> For example, "no `implementation is free to extend the
> syntax' of DEFCLASS."
>
>I maintain that any such prohibition is meaningless, or at least
>unenforceable. How does this differ from "the consequences are
>undefined if DEFCLASS is invoked with syntax other than that specified
>in the standard"? In both cases, it means that a portable program may
>not depend on the behavior. What business do we have constraining how
>an implementation deals with nonportable programs?
>If you want to constrain implementations, it should be done with a
>requirement rather than a prohibition. For instance, "an 'error is
>signalled' if DEFCLASS is invoked with syntax not conforming to this
>specification". This prevents syntax extensions because it would break
>a portable program that relies on the error being signalled.
I agree, but would like to hear from the CLOSers about why a prohibition
rather than a requirement was used in this case.
My recollection about this whole issue was that the CLOSers were going
to change this stuff to refer to what an implementation is permitted to
DOCUMENT about its behavior, e.g. "no implementation is free to extend
the syntax of DEFCLASS and document that extension as a feature of the
implementation."
> - A "WARNING IS ISSUED"
>
> means that
>
> - If this situation occurs, a warning is issued, as
> described in WARN, in both safe and unsafe situations.
>
> - Valid programs may rely on the fact that a warning will be
> issued in both safe and unsafe situations.
>
> - Every implementation is required to detect this situation
> in both safe and unsafe situations.
>
> For example, "a `warning is issued' by the compiler if a
> declaration specifier is not one of those defined in Chapter 9
> of CLtL and has not been declared in a DECLARATION
> declaration."
>
>This doesn't say what the results are in such situations.
Which results? which situation?
The results of a form whose evaluation/compilation results in a warning,
e.g.
(defun foo (a)
(declare (frobnitz a))
a)
This will result in a compiler warning because of the unrecognized
declaration. Is the return value well defined?
>
> - A "WARNING SHOULD BE ISSUED"
>
> means that
>
> - If this situation occurs, a warning will be issued at
> least in safe situations.
>
> - Valid programs may not rely on the fact that a warning
> will be issued.
>
> - Every implementation is required to detect such a
> situation at least in safe situations.
>
>
> For example, "a warning `should be issued' by a compiler
> if a variable declared to be ignored is ever referred to or is
> also declared special, or if a variable is lexical, never
> referred to, and not declared to be ignored." (see Chapter 9,
> CLtL)
>
>Both "warning" examples only mention warnings issued by the compiler.
>In that case, what is the distinction between safe and unsafe
>situations? The definitions of "safe" and "unsafe" specify "when code
>is run"; is there any situation in which a warning is/should be issued
>at run time?. At compile time the only code that is run is the compiler
>itself (which I would assume is generally compiled with the lowest
>safety level before being shipped to customers) and any macros used in
>the program (and any implementation-supplied macros will also probably
>be compiled with lowest safety, and there is no way for portable,
>user-written macros to access the safety level), but I don't think this
>section is referring to either of them.
Currently in CLtL the only time warnings are mentioned is in conjunction
with the compiler (did I miss something?). However, is there a problem
with generalizing warnings?
If warnings are only issued by the compiler, then what does the
reference to safe vs unsafe situations mean?
barmar
∂03-Oct-88 1125 CL-Editorial-mailer
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 11:25:06 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA01582; Mon, 3 Oct 88 11:22:53 PDT
Message-Id: <8810031822.AA01582@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 13:57
To: barmar@think.com, cl-editorial@sail.stanford.edu,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Subject:
> There are two principal reasons why this language permits
> a situation to have an undefined consequence rather than
> requiring an error to be signalled:
>
> ...
>
> - The situation can be implemented as an extension.
>
>If this is the case, then what is the difference between "CONSEQUENCES
>ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
The definitions of these two phrases are different, one just happens to
indirectly refer to the other.
>Please explain the difference. Describe a situation where one is true
>yet the other isn't.
The way I see it is that one general situation provides examples of both
cases: it is generally true in CL that the consequences are undefined
if "incorrect" arguments are supplied during a function call. Sometimes
an implementor may wish to extend the implementation so that a wider range
of arguments is accepted than is specified. In other cases that doesn't make
any sense or isn't possible.
> - THE "CONSEQUENCES ARE UNSPECIFIED"
>
>I also don't care for this particular term. "Unspecified" and
>"undefined" are too similar in meaning. How about "consequences are
>undefined but benign"?
Instead of "CONSEQUENCES ARE UNSPECIFIED"?
>Yes.
Isn't that basically the way "consequences are unspecified" is defined
in the text that follows it? You want fewer words to have to remember
the meanings of, right? But, as KMP pointed out, the words "benign"
and "harmless" mean different things to different programs. Therefore
changing the wording in this case to be exact would require the
following phrase each time the "consequences are unspecified":
"consequences are undefined but, by themselves, won't cause abnormal
termination" or something like that.
Would that be better?
> The standard may disallow certain extensions while
> allowing others.
>
> For example, "no `implementation is free to extend the
> syntax' of DEFCLASS."
>
>I maintain that any such prohibition is meaningless, or at least
>unenforceable. How does this differ from "the consequences are
>undefined if DEFCLASS is invoked with syntax other than that specified
>in the standard"? In both cases, it means that a portable program may
>not depend on the behavior. What business do we have constraining how
>an implementation deals with nonportable programs?
>If you want to constrain implementations, it should be done with a
>requirement rather than a prohibition. For instance, "an 'error is
>signalled' if DEFCLASS is invoked with syntax not conforming to this
>specification". This prevents syntax extensions because it would break
>a portable program that relies on the error being signalled.
I agree, but would like to hear from the CLOSers about why a prohibition
rather than a requirement was used in this case.
>My recollection about this whole issue was that the CLOSers were going
>to change this stuff to refer to what an implementation is permitted to
>DOCUMENT about its behavior, e.g. "no implementation is free to extend
>the syntax of DEFCLASS and document that extension as a feature of the
>implementation."
That's still a prohibition. How should it be reworded into a requirement?
> - A "WARNING IS ISSUED"
>
> means that
>
> - If this situation occurs, a warning is issued, as
> described in WARN, in both safe and unsafe situations.
>
> - Valid programs may rely on the fact that a warning will be
> issued in both safe and unsafe situations.
>
> - Every implementation is required to detect this situation
> in both safe and unsafe situations.
>
> For example, "a `warning is issued' by the compiler if a
> declaration specifier is not one of those defined in Chapter 9
> of CLtL and has not been declared in a DECLARATION
> declaration."
>
>This doesn't say what the results are in such situations.
Which results? which situation?
>The results of a form whose evaluation/compilation results in a warning,
>e.g.
>
>(defun foo (a)
> (declare (frobnitz a))
> a)
>
>This will result in a compiler warning because of the unrecognized
>declaration. Is the return value well defined?
What would be the return value if no warning were issued? The presence
or absence of a warning should have no effect on the result, and that
should be stated here. Right?
>
> - A "WARNING SHOULD BE ISSUED"
>
> means that
>
> - If this situation occurs, a warning will be issued at
> least in safe situations.
>
> - Valid programs may not rely on the fact that a warning
> will be issued.
>
> - Every implementation is required to detect such a
> situation at least in safe situations.
>
>
> For example, "a warning `should be issued' by a compiler
> if a variable declared to be ignored is ever referred to or is
> also declared special, or if a variable is lexical, never
> referred to, and not declared to be ignored." (see Chapter 9,
> CLtL)
>
>Both "warning" examples only mention warnings issued by the compiler.
>In that case, what is the distinction between safe and unsafe
>situations? The definitions of "safe" and "unsafe" specify "when code
>is run"; is there any situation in which a warning is/should be issued
>at run time?. At compile time the only code that is run is the compiler
>itself (which I would assume is generally compiled with the lowest
>safety level before being shipped to customers) and any macros used in
>the program (and any implementation-supplied macros will also probably
>be compiled with lowest safety, and there is no way for portable,
>user-written macros to access the safety level), but I don't think this
>section is referring to either of them.
Currently in CLtL the only time warnings are mentioned is in conjunction
with the compiler (did I miss something?). However, is there a problem
with generalizing warnings?
>If warnings are only issued by the compiler, then what does the
>reference to safe vs unsafe situations mean?
It's not necessarily true forever that warnings are only issued by the
compiler, only for now, in the stage we're in now. If we find, when the
standard is complete, that warnings are only issued by the compiler, then
we'll take the safe/unsafe business out. Right?
kc
∂03-Oct-88 1233 CL-Editorial-mailer October agenda
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 12:33:12 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05665; Mon, 3 Oct 88 12:31:38 PDT
Message-Id: <8810031931.AA05665@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 14:58
To: @[chapman]editors@decwrl.dec.com
Subject: October agenda
Agenda - October Meeting
Editorial Committee
Fairfax, Virginia
Following are the proposed agenda items for the Virginia
meeting. Please feel free to request the addition or deletion of
items (except lunch). Speaking of lunch, since the editorial
meeting begins as soon as the clean-up meeting completes, Bob
Mathis has seen to it that we don't starve. There will be food
available close to where we'll be meeting so we can work while we
eat.
Agenda:
1. Error Terminology plus lunch (15 minutes)
2. Conformance (15 minutes)
3. Extensions (15 minutes)
4. Language subsetting (15 minutes)
5. General comments about the review so far (30 minutes)
We must consider a new name for the
Environment/Evaluation section, and a term to replace "tool".
6. Break into groups to examine the document (1.5 hours)
This will involve deciding if there is enough explanatory
material in the chapter you are reviewing to make the
specification clear.
- Group 1: Chapters 1 and 3 - Intro and reader
- Group 2: Chapter 2 - Types
- Group 3: Chapter 4 - Evaluation
- Group 4: Chapter 5 - Errors, IO, and generalized
reference
7. Reconvene and collect comments (1 hour)
∂03-Oct-88 1255 CL-Editorial-mailer error definitions
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Oct 88 12:55:18 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 3 Oct 88 15:18:04 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 3 Oct 88 15:49:34 EDT
Date: Mon, 3 Oct 88 15:49 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: error definitions
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, DJAHANDARI%TOWNS.DEC@decwrl.dec.com,
POPA%TOWNS.DEC@decwrl.dec.com
In-Reply-To: <8810031822.AA01582@decwrl.dec.com>
Message-Id: <19881003194959.0.BARMAR@OCCAM.THINK.COM>
Date: 3 Oct 88 13:57
From: chapman%aitg.DEC@decwrl.dec.com
>If this is the case, then what is the difference between "CONSEQUENCES
>ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
The definitions of these two phrases are different, one just happens to
indirectly refer to the other.
>Please explain the difference. Describe a situation where one is true
>yet the other isn't.
The way I see it is that one general situation provides examples of both
cases: it is generally true in CL that the consequences are undefined
if "incorrect" arguments are supplied during a function call. Sometimes
an implementor may wish to extend the implementation so that a wider range
of arguments is accepted than is specified. In other cases that doesn't make
any sense or isn't possible.
You're talking about the implementor here. What is the difference IN
THE STANDARD? Why would the standard say "undefined" in one place and
"may be extended" in another. To the implementor, both mean "you can do
what you want"; to the user, both mean "you can't do this in portable
code."
> - THE "CONSEQUENCES ARE UNSPECIFIED"
>
>I also don't care for this particular term. "Unspecified" and
>"undefined" are too similar in meaning. How about "consequences are
>undefined but benign"?
Instead of "CONSEQUENCES ARE UNSPECIFIED"?
>Yes.
Isn't that basically the way "consequences are unspecified" is defined
in the text that follows it? You want fewer words to have to remember
the meanings of, right? But, as KMP pointed out, the words "benign"
and "harmless" mean different things to different programs. Therefore
changing the wording in this case to be exact would require the
following phrase each time the "consequences are unspecified":
"consequences are undefined but, by themselves, won't cause abnormal
termination" or something like that.
Would that be better?
All I'm asking is that we not use synonyms this way. If you can come up
with a better phrase than mine, by all means use it. But "undefined"
and "unspecified" mean the same thing to me, and if I were an
implementor I wouldn't want to have to remember which one is which.
> The standard may disallow certain extensions while
> allowing others.
>
> For example, "no `implementation is free to extend the
> syntax' of DEFCLASS."
>
>I maintain that any such prohibition is meaningless, or at least
>unenforceable. How does this differ from "the consequences are
>undefined if DEFCLASS is invoked with syntax other than that specified
>in the standard"? In both cases, it means that a portable program may
>not depend on the behavior. What business do we have constraining how
>an implementation deals with nonportable programs?
>If you want to constrain implementations, it should be done with a
>requirement rather than a prohibition. For instance, "an 'error is
>signalled' if DEFCLASS is invoked with syntax not conforming to this
>specification". This prevents syntax extensions because it would break
>a portable program that relies on the error being signalled.
I agree, but would like to hear from the CLOSers about why a prohibition
rather than a requirement was used in this case.
>My recollection about this whole issue was that the CLOSers were going
>to change this stuff to refer to what an implementation is permitted to
>DOCUMENT about its behavior, e.g. "no implementation is free to extend
>the syntax of DEFCLASS and document that extension as a feature of the
>implementation."
That's still a prohibition. How should it be reworded into a requirement?
In this case, a prohibition works, because it is talking about something
concrete. You can't prohibit an implementation from defining the
behavior of some construct, because there's no such thing as undefined
behavior in an implementation (it's empirically defined to do whatever
it does when the situation occurs). You can, however, prohibit the
implementor from publicizing the behavior. I don't happen to like this,
but at least it makes sense.
We may, however, have to be even more careful in our wording of this
issue. For example, if an implementation documents that an error will
be signalled if the :FOOBAR keyword is given to DEFCLASS, is that an
extension? It defines the behavior in a situation not specifically
mentioned in the standard, right? I imagine we would like to allow this
form of extension, but disallow some others.
>This will result in a compiler warning because of the unrecognized
>declaration. Is the return value well defined?
What would be the return value if no warning were issued? The presence
or absence of a warning should have no effect on the result, and that
should be stated here. Right?
All I'm asking for is that the standard specifically state that the
warning will have no effect on the actual operation.
>If warnings are only issued by the compiler, then what does the
>reference to safe vs unsafe situations mean?
It's not necessarily true forever that warnings are only issued by the
compiler, only for now, in the stage we're in now. If we find, when the
standard is complete, that warnings are only issued by the compiler, then
we'll take the safe/unsafe business out. Right?
Since the safe/unsafe business doesn't make sense for compiler warnings,
we should decide that all compiler warnings will be "A WARNING WILL BE
ISSUED" rather than "SHOULD BE", since "SHOULD BE" has no meaning for
compiler warnings. Then your above statement becomes "if we find that
'WARNING SHOULD BE' is never used, then we can take it out."
barmar
∂03-Oct-88 1406 CL-Editorial-mailer Error Terminology
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'm not following the debate on this, but I see the question raised
about what these two phrases mean:
1. ``consequences are undefined''
2. ``implementations may be extended''
To implementors these say:
1. you can do whatever you want, but don't waste effort
on doing something useful because it will be ignored.
2. you can do whatever you want, and something useful would be nice.
To users these say:
1. never use this.
2. read your vendor's manual to find out about useful behavior,
but don't use this in portable code.
I think these are different in both cases, so both terminologies are
needed. Why do I think that implementors should be told not to extend
something? Because we have moved into the era when language designers know
more about language design than implementors, at least in some cases.
I think some of the cleanup mail I've seen recently proves it.
-rpg-
∂03-Oct-88 1429 CL-Editorial-mailer Error Terminology
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Oct 88 14:29:12 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 3 Oct 88 16:54:02 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 3 Oct 88 17:26:07 EDT
Date: Mon, 3 Oct 88 17:26 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Error Terminology
To: Dick Gabriel <RPG@sail.stanford.edu>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <OlxIJ@SAIL.Stanford.EDU>
Message-Id: <19881003212644.4.BARMAR@OCCAM.THINK.COM>
Date: 03 Oct 88 1406 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
I'm not following the debate on this, but I see the question raised
about what these two phrases mean:
1. ``consequences are undefined''
2. ``implementations may be extended''
To implementors these say:
1. you can do whatever you want, but don't waste effort
on doing something useful because it will be ignored.
2. you can do whatever you want, and something useful would be nice.
To users these say:
1. never use this.
2. read your vendor's manual to find out about useful behavior,
but don't use this in portable code.
I think these are different in both cases, so both terminologies are
needed. Why do I think that implementors should be told not to extend
something? Because we have moved into the era when language designers know
more about language design than implementors, at least in some cases.
I think some of the cleanup mail I've seen recently proves it.
-rpg-
If that is what is meant, then the descriptions should be a little more
explicit in this regard. For example, the description of "may be
extended" should say that implementors are encouraged to experiment with
this situation.
Actually, I don't think these things belong in the main body of the
standard. Standards generally have annexes for things like rationales
and implementation suggestions. Suggestions regarding extensions also
belong there, because they don't affect the official, portable language
that is being defined in the body of the standard. I believe the C
standard has an annex describing common extensions and another one
suggesting possible extensions. These extensions are likely to become
part of the next version of the standard, and these annexes encourage
experimentation with the features so that there will be enough
experience to codify the practice in a couple of years.
barmar
∂04-Oct-88 0951 CL-Editorial-mailer barmar questions about error terms
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 4 Oct 88 09:51:29 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02128; Tue, 4 Oct 88 09:49:51 PDT
Message-Id: <8810041649.AA02128@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 4 Oct 88 11:42
To: @[chapman]editors@decwrl.dec.com
Subject: barmar questions about error terms
1. CONSEQUENCES ARE UNDEFINED vs IMPLEMENTATIONS MAY BE EXTENDED
RPG's clarifications will be included in the descriptions of these two
categories, the categories will remain distinct. In regard to your comment
that these things don't belong in the standard, you're right that the
actual information about possible extensions doesn't belong in the standard.
But what does belong there are words that cover each situation. If a
situation isn't explicitly addressed, the standard is incomplete.
Do you agree?
2. CONSEQUENCES ARE UNSPECIFIED
How about CONSEQUENCES ARE UNDEFINED BUT NONTERMINAL?
3. IMPLEMENTATIONS ARE FREE TO EXTEND THE SYNTAX
We should find out from the CLOSers what the final word in the case
of the DEFCLASS prohibition was. Additionally we need to locate any
other prohibitions in the standard and reword them (carefully) accordingly.
Agreed?
4. WARNING IS ISSUED
New item in the description states that the warning has no effect on
the operation.
5. WARNING SHOULD BE ISSUED
Right, if warnings only apply to the compiler, according to this definition,
this category will go away. However, I believe CLtL must have another
definition for warnings since the two ways to get a warning (IS ISSUED,
SHOULD BE ISSUED) are both present in CLtL.
Any historical information?
kc
∂04-Oct-88 1101 CL-Editorial-mailer Error Terminology
To: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I read:
``We should find out from the CLOSers what the final word in the case
of the DEFCLASS prohibition was. Additionally we need to locate any
other prohibitions in the standard and reword them (carefully) accordingly.''
The main point with DEFCLASS is that we wanted it to be the case that
everyone who dealt with DEFCLASS including codewalkers knew exactly what
the portable syntax was. Also, because every underlying mechanism to build
DEFCLASS and like things is exposed and available to users, there is no
need to allow extensions.
On ``...is undefined'':
Requiring an error or warning to be signaled and prohibiting an extension
are not equivalent, because it might be implementationally expensive to
detect such situations. Hence, the need for prohibitions.
I might point out that the CLOS committee didn't come up with this
terminology as a joke or in a fit of stupidity. Nor did we accidentally
forget the CLtL terminology. We designed it deliberately and in full
knowledge that it differed from CLtL terminology. Furthermore, we used
that terminology very carefully in the CLOS document.
-rpg-
∂04-Oct-88 2041 X3J13-mailer Re: error definitions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Oct 88 20:41:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 88 19:59:52 PDT
Date: Tue, 4 Oct 88 19:59 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: error definitions
To: Barry Margolin <barmar@Think.COM>, Dick Gabriel
<RPG@SAIL.Stanford.EDU>, chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.Stanford.EDU, x3j13@sail.stanford.edu,
DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881003194959.0.BARMAR@OCCAM.THINK.COM>,
<OlxIJ@SAIL.Stanford.EDU>,
<19881003212644.4.BARMAR@OCCAM.THINK.COM>,
<8810031951.AA06841@decwrl.dec.com>,
<km9wo@SAIL.Stanford.EDU>
Message-ID: <19881005025941.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 04 Oct 88 11:01 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I might point out that the CLOS committee didn't come up with this
terminology as a joke or in a fit of stupidity. Nor did we accidentally
forget the CLtL terminology. We designed it deliberately and in full
knowledge that it differed from CLtL terminology. Furthermore, we used
that terminology very carefully in the CLOS document.
Right, and more detail about this to follow.
Date: 03 Oct 88 14:06 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'm not following the debate on this, but I see the question raised
about what these two phrases mean:
1. ``consequences are undefined''
2. ``implementations may be extended''
This terminology was introduced after a great deal of thought about how
to prevent the so called "number of arguments to IF" bug. We believe
that we have restricted the syntactic extensions that can be made to
CLOS, and that that restriction is important for a variety of reasons.
CLOS is a language which provides a great deal of extensibility, and
given that it is a very important concept to be able to restrict that
in places where it is appropriate.
- THE "CONSEQUENCES ARE UNSPECIFIED"
I am not up to speed on this issue, and I am tired, but I believe it is
important that "THE CONSEQUENCES ARE UNSPECIFIED" must not include
"IMPLEMENTATIONS MAY BE EXTENDED" in any way.
-------
∂05-Oct-88 0021 CL-Editorial-mailer Re: Error Terminology
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 00:20:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 OCT 88 00:16:16 PDT
Date: 5 Oct 88 00:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Error Terminology
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 04 Oct 88
11:01 PDT
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-editorial@SAIL.Stanford.EDU
Message-ID: <881005-001616-4504@Xerox>
I think the CL standard actually needs the rather painful work of going
through the standard, finding all of the places that currently say "is an
error" or "signals an error" or "must", and recasting them in the new error
terminology:
I don't know who would volunteer for such a job, since it is difficult and
at risk of being political.
∂14-Oct-88 1149 CL-Editorial-mailer proposal for specification of standard features
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Oct 88 11:49:09 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
id AA26080; Fri, 14 Oct 88 12:49:00 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA20446; Fri, 14 Oct 88 12:48:57 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810141848.AA20446@defun.utah.edu>
Date: Fri, 14 Oct 88 12:48:56 MDT
Subject: proposal for specification of standard features
To: cl-editorial@sail.stanford.edu
This message proposes a mechanism for dealing with two related
problems that have been cropping up from time to time:
(1) What to do with functionality that is described in CLtL but that
some people would now like to remove from the standard language,
while still allowing implementations to provide that functionality
as an extension. (For example, the cleanup issue TEST-NOT-IF-NOT.)
(2) New functionality not described in CLtL that we would like to
standardize, but that some people would not like to make a required
part of the language. (For example, the fancy LOOP macro.)
I'm not really sure if the editorial committee is the right place to send
this, but given that we don't have conformance or subsetting committees
I don't know where else would be more appropriate.
What I'm suggesting is that the language include the concept of
"standard features". The general idea is that the functionality would
be described in the standard but that implementations would not be
required to support it. We would assign each feature a standard name
for *FEATURES* so that user programs can identify whether or not the
feature is present in a particular implementation.
A proposal to make something a standard feature should include at least
the following kinds of information:
Feature Name:
[ A keyword suitable for *FEATURES*.]
Description:
[ A brief narrative description of the functionality included
in this feature; it shouldn't need to be more than one
or two sentences.]
Category:
[ Either CHANGE, for purpose (1) above, or ADDITION, for
purpose (2).]
Motivation:
[ Why should this functionality be optional instead of a required
part of the language? Typical reasons would include that
the feature is now considered obsolete but might be
provided for compatibility with existing code, or that
the feature is "large" and might not be used at all by
many programs.]
Functions/Macros/Variables/Types/etc included:
[ List all functions that are not present at all if the feature
is not supported by a particular implementation.]
Functions/Macros/Variables/Types/etc modified:
[ List all functions that behave differently if the feature is not
supported by a particular implementation, than when the
feature is supported. Be specific about what the
differences are.]
Packages and Symbols:
[ Does this feature reside in its own package? What are all of
the external symbols used by this feature?]
This last section on packages is kind of sticky. I suspect that most
CHANGEs would want to continue to reside in the LISP package, which
raises the issue of whether the symbols they use should still appear
as external symbols even when the feature is not present. Most
ADDITIONs would probably live in their own packages.
It might also be a good idea to try to lay down some general rules
about functions whose behavior is modified by a feature. For example,
it's important the features that extend existing functions should
guarantee that those extensions are compatible -- any program that's
valid if the feature isn't present should continue to be valid if the
feature is present. I think it is also a good idea to encourage
"signalling an error" when a feature isn't present instead of just
saying "is an error", particularly when uses of the unsupported
feature are easy to detect. For example, if the fancy LOOP macro is
adopted as an optional feature, it would be reasonable to require
implementations that don't support it to signal an error if they see
atomic forms in the body of a loop. For simplicity, we could probably
define a single unsupported-feature error to be used for all
situations instead of each feature defining its own peculiar kind of
errors.
I'd be interested in getting some feedback on this idea. Not having
seen the draft of the document yet, I have no idea how standard
features would fit in to its overall organization. Is there anything
else that would have to be included in the writeup format?
Note that I'm not on the cl-editorial mailing list, so please make sure
that further discussion on this is cc'ed to me explicitly.
-Sandra
-------
∂18-Oct-88 0922 CL-Editorial-mailer next meeting
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88 09:21:54 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03654; Tue, 18 Oct 88 09:21:45 PDT
Message-Id: <8810181621.AA03654@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Oct 88 12:17
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: next meeting
I'm thinking of requesting a vote of confidence at the next meeting. To do this
I have to get the phase 1 document to the X3J13 committee by Dec. 17 (or
thereabouts).
What do you think?
kc
∂18-Oct-88 1229 CL-Editorial-mailer editorial committee meeting notes
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88 12:28:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05255; Tue, 19 Apr 88 20:24:19 PDT
Message-Id: <8804200324.AA05255@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Oct 88 15:25
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
POPA%TOWNS.DEC@decwrl.dec.com, DJAHANDARI%TOWNS.DEC@decwrl.dec.com
Subject: editorial committee meeting notes
Editorial Committee Meeting
October 10, 1988, Fairfax, Virginia
Attendees: Jim Allard, Mary Boelke, Skona Brittain, Kathy
Chapman, Dick Gabriel, Gregor Kiczales, Barry Margolin, Larry
Masinter, Bob Mathis, Kent Pitman, Jeff Rosenking, Guy Steele,
Walter van Roggen
For a short time some compiler committee members were
present: Kim Barrett, Steve Havlitch, Sandra Loosemore, and JonL
White.
1 SUMMARY OF ACTION ITEMS
Editor: correct error proposal; include more information
about conformance and extensions and send to X3J13 along with
requests for volunteers to investigate subsetting. Complete
including comments from section writers. Create schedule for
phase 2 review that includes final reviews by Steele, Gabriel, and
Moon.
Section writers: review my responses to your comments and
begin accepting phase 2 portions of the document as they are
completed by the editor. Review chapters 1 - 5 for consistency
and clarity.
Larry Masinter: begin assisting me in incorporating issues.
New list of section writers:
Person Responsibilities
Jim Allard Files, Hashtables, Lists, Predicates
Mary Boelke Packages, Symbols
Skona Brittain Control Structure, Sequences
Kathy Chapman Editor (see list of responsibilities below)
Chapters 1, 3, 5, 7, 8, Glossary
Make up glossary of error terms, get approved by
error, edit, and CLOS committees
Create a proposal for handling language subsets
Bob Kerns Characters, Strings, Chapter 2
Gregor Kiczales CLOS
Barry Margolin Arrays, Evaluator, IO, Structures
Larry Masinter Incorporating clean-up issues
!
Page 2
Bob Mathis Numbers
Jeff Piazza Declarations
Kent Pitman Chapter 2, Errors, Miscellaneous, Types
Jonathan Rees Chapter 4
Jeff Rosenking Macros, Streams
Walter van Roggen Program Structure
2 SUMMARY OF MEETING
New order and header definitions for the tools descriptions in
Chapter 6 were proposed and accepted:
Syntax
Method Signatures
Arguments -- a list of the arguments required by the function,
macro, or special form, and the required aspects of each
argument.
Values -- a list of the values returned by each function,
macro, or special form, and the required aspects of each
value.
Description -- contains a combination of the current
`Description' and `Environment/Evaluation' sections.
Examples -- although they must be correct, examples aren't
part of the requirements portion of the standard.
Side Effects
Affected By
Conditions
Notes -- contains no requirements, only peripheral
information.
See Also -- contains references only to items that aren't
referred to elsewhere.
A glossary of terms will be composed to be used to simplify the
process of describing the arguments and values. Also, when
feasible, Lisp should be used. For example:
!
Page 3
make-array dimensions ...
Dimensions -- (or (integer 0 *) list)
The error terminology paper was discussed and specific
suggestions for improvement were made. It is clear that
conformance and extensions can't be divorced from error
terminology, so those topics will appear somewhere in detail in
the revised version of the paper that I will write. I will also
include proposed translations from CLtL to the new terminology so
that reviewers can begin to understand the impact of changing
things.
The X3J13 committee needs to decide what to do about
deprecation. Research in this area needs to be done. Volunteers
will be requested, but if there are none, I will summarize what I
can learn about what other languages have done in this area.
The X3J13 committee needs to decide what to do about language
subsets. Research in this area needs to be done. Volunteers will
be requested, but if there are none, I will summarize what
research has been done in this area.
Gregor has agreed to work with me to add the CLOS
specification to the standard.
∂18-Oct-88 1436 CL-Editorial-mailer subsetting/features
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88 14:35:50 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10826; Tue, 19 Apr 88 22:31:16 PDT
Message-Id: <8804200531.AA10826@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Oct 88 16:47
To: cl-editorial@sail.stanford.edu, sandra@cs.utah.edu
Subject: subsetting/features
Sandra,
I am in the process of trying to locate precedents in other languages
that pertain to your proposal. I will summarize comments when I have
received them all.
So far the comments have been in the vain of discouraging subsetting.
kc
∂18-Oct-88 1539 CL-Editorial-mailer Re: proposal for specification of standard features
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Oct 88 15:39:26 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 14:28:51 PDT
Date: 18 Oct 88 14:18 PDT
From: masinter.pa@Xerox.COM
Subject: Re: proposal for specification of standard features
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Fri, 14 Oct 88 12:48:56 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-editorial@sail.stanford.edu
Message-ID: <881018-142851-5100@Xerox>
I like the idea of separating out features that are OBSOLETE and also of
providing a section in the standard for FUTURE ADDITIONS -- things that
we're not ready to add to the standard but for which experimentation is
encouraged.
I think we'll make more progress on the mechanism once we have a shared
idea of what falls into each category.
For example, I don't like the idea so much of making *FEATURES* the primary
mechanism for determining which are present and which are not in a given
implementation. *FEATURES* are good for things that are necessarily
different from one implementation to the next, where programmers must find
themselves writting #+ieee-floating-point or #-symbolics. This seems less
useful a way of describing obsolete features, etc.α∂
I'm not even sure we have to dictate the mechanism by which implementations
identify whether they are CLtL Common Lisp or ANSI Common Lisp or ANSI
Common Lisp Without Obsolete Definitions. Do we?
∂18-Oct-88 1611 CL-Editorial-mailer Re: proposal for specification of standard features
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Oct 88 16:11:11 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
id AA23010; Tue, 18 Oct 88 17:11:03 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA23162; Tue, 18 Oct 88 17:11:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810182311.AA23162@defun.utah.edu>
Date: Tue, 18 Oct 88 17:10:58 MDT
Subject: Re: proposal for specification of standard features
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs (Sandra J Loosemore), cl-editorial@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 18 Oct 88 14:18 PDT
I agree that *features* isn't really the best mechanism for handling
this; I don't imagine that programmers would find it very useful to do
things like #+loop-macro, for instance. It's the best I could come up
with on short notice, though; maybe somebody else can think of a better
mechanism. That's really the reason why I brought this up now -- to get
people to think about it more seriously, instead of just hand-waving
about how we might make certain things optional "later on".
Also, I should point out that there are a number of issues (some
cleanup proposals as well as the iteration proposals) now pending that
I would vote differently on if we had a mechanism like this in place.
-Sandra
-------
∂28-Oct-88 0346 CL-Editorial-mailer mailing list update
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Oct 88 03:46:46 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22919; Fri, 28 Oct 88 03:46:27 PDT
Message-Id: <8810281046.AA22919@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Oct 88 06:43
To: cl-editorial@sail.stanford.edu
Subject: mailing list update
Please remove Ron Ohlander from cl-editorial.
∂28-Oct-88 1613 CL-Editorial-mailer A Note on Examples For Standard
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88 07:02:25 PDT
Date: 27 Oct 1988 10:01-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: A Note on Examples For Standard
From: ROSENKING@A.ISI.EDU
To: cl-editorial@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]27-Oct-88 10:01:17.ROSENKING>
I just thought I'd pass on a note of good advice which Dave Moon gave to me
after I suggested a modification to an example in the draft standard:
We need to be careful of putting examples in documentation that
imply that the language specification is more restrictive than
it was intended to be.
∂07-Nov-88 1742 CL-Editorial-mailer "arguments to a @i(form)"
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Nov 88 17:41:47 PST
Return-Path: <@occam.think.com:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 7 Nov 88 15:19:31 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 7 Nov 88 15:38:12 EST
Date: Mon, 7 Nov 88 15:39 EST
From: Barry Margolin <barmar@Think.COM>
Subject: "arguments to a @i(form)"
To: cl-editorial@sail.stanford.edu
Message-Id: <19881107203905.4.BARMAR@OCCAM.THINK.COM>
The phrase "arguments to a @i(form)" appears frequently in the draft
standard, but I don't really like it. Forms don't get arguments,
functions do. A form that is a function call has subforms that are
evaluated to produce arguments for the function. I believe that the
above phrase should generally be "arguments to a @i(function)".
Kathy, is there some reason the current terminology was used?
Currently, the Definitions section of the standard is nearly empty, so
perhaps you intended some other definition of "form" than the one
commonly used in the Lisp community?
Comments?
barmar